RFC: An alternative to /usr/share/java/repository
I have been giving a lot of thought to the policy that Stephane has
proposed. While I certainly appreciate the sentiment that has caused
him to push for adoption so strongly I still am not wholly satisfied
with the direction of his efforts.
I do understand that Debian policy discourages the concept of a
program requiring that an environment variable be set in order to
operate sanely. Unfortunatly, one of the key design decisions in the
Java language is this notion of class repositories that are defined
through the CLASSPATH environment variable. Stephane's solution has
been to essentially disable the use of this feature within the Debian
system. This has some disadvantages that I find difficult to accept:
- Users cannot easily pick and choose which sets of classes they would
like to use out of a group of installed java class sets. The only
way that they can do this is to download the jars from a seperate
site and put them into their classpath.
ie. CLASSPATH=/home/ean/jars/jigsaw.jar:/usr/share/java/repository
This defeats the basic purpose of the dpkg/apt system (installing
packages) and in that sense defeats the purpose of Debian.
- It is not possible to install multiple implementations of the same
class domain with the repository scheme. If you have a GTK
implmentation of the AWT and a Xlib implementation they will both
include java.awt.* classes and must therefore conflict. This is
what the jar mechanism works to allow and is too important a
feature to remove.
I understand the motivation to establish the scheme that Stephane has
selected because it provides an obvious and immediate solution to the
problem of transparently activating new java classes when installed.
I contemplated this same scheme some time ago but discarded it when
most of the issues above were posed to me. There are alternatives to
this scheme, however, that offer similar utility and do not suffer
from the encumberances of Stephane's outlined method.
The best advice is perhaps to follow what policy actually states as
the technique for dealing with programs that require an environment
setting, a wrapper script. It is fairly trivial (1 line of shell code)
to read in a list of configured classpaths from a folder in /etc and
use these to build a classpath for the VM being spawned.
Adam Heath and I have been discussing an arrangement where each
package of classes would place a file marked as a configuration file
into some central directory, say, /etc/classpaths. Each of these
configuration files would contain a list of class locations as below:
[file /etc/classpaths/00kaffe.classes]
/usr/share/kaffe/Klasses.jar
/usr/share/kaffe/microsoft.jar
/usr/share/kaffe/rxtx.jar
These files would be aggregated to form a final classpath that the VM,
or other program, would use. This can be done easily in a single line
of shell code and even provide a notion of comments and priority. This
way you can do something like...
[file /etc/classpaths/00kaffe.classes]
/usr/share/kaffe/Klasses.jar
#/usr/share/kaffe/microsoft.jar
/usr/share/kaffe/rxtx.jar
with an ease that is not possible under Stephane's proposed system.
The notion of priority, ala rc.d, is also interesting. You might see
the contents of /etc/classpaths looking something like:
00kaffe.classes
10classpath-servlet.classes
11sun-servlet.classes
Or some system that allows the order of inclusion in the CLASSPATH to
be built easily. Also, it would probably be nice to have a notion of a
symbol that represents the dynamically constructed CLASSPATH portion.
A symbol such as DEBIAN_CLASSES could be used. This way, if you set
your CLASSPATH to:
CLASSPATH=/home/ean/jars/myevilstuff.jar:DEBIAN_CLASSES
The shell script would do the proper expansion when calling the VM.
This would allow you to customize the classpath and still get the
benefits of dynamic jar inclusion.
I know that it is a bit late in the game to get this concept into
freeze but I don't think it is that big a stretch to get it put
together this weekend. I am considering putting it into the kaffe
package in some form whether it is adopted on a wider basis or not.
I frankly don't intend to follow the current Java policy as it stands
because I simply don't think that it is the right way to solve the
problem. I hope that it is understood that my motivation for taking
that stance is purely one of design principal and not a desire to
simply be mean.
If this idea is recieved favorably perhaps it and some other
formalizations can be folded into some final and genuine java policy.
E
--
___________________________________________________________________
Ean Schuessler An oderless programmer work-a-like
Novare International Inc. Silent and motionless
*** WARNING: This signature may contain jokes.
Reply to: