Re: Java libraries and proposal.
> Java libraries:
> * Java libraries should go to /usr/share/java if they are
> jar files and /usr/share/java/repository if they are a collection
> of classes.
Well, being a big fan of Tomcat, I'd much more prefer to see .jar files in
"/usr/share/java/lib" and .class hierarchies in "/usr/share/java/classes".
To prevent name clashes of .jar files, we may or may not want to
support/encourage putting .jar files in subdirectories within
/usr/share/java/lib.
> * The jar file should be named name-version.jar and defaults
> should be a symbolic link with the name name.jar
> Quite the same way as C-libraries.
Nice idea. It lets individual users stay with a particular version if they
specify the fully-versioned .jar name.
> * Here is a proposal. API dependencies should be specified in
> a way so that it should be easy to set the classpath.
I'm not sure I follow you. I was under the impression that the
/usr/share/java class hierarchy and all of the jars would be auto-included
into the classpath whenever you run java/javac/javadoc/whatever. If that's
the case, then dependencies don't matter since you always get the whole
enchilada.
> Jvm:
> * .so files should be placed in /usr/lib
> * We should find a way to make it possible to use switch between
> java virtual machines without having to reset the classpath or similar.
Yes, yes, yes! Also, if possible, I'd like the individual users to be able
to set an environment variable that picks which JVM gets run when they want
to invoke a JVM. (This might be treading a little too close to the edge of
legality, since I think Sun's Java license says something like: If the user
types "javac", they'd better get the compiler from the JDK.)
> But maybe this simply is too early.
How so? Why can't you do this:
1 - Put non-JVM-specific classes and jars in /usr/share/java (hence the
word "share").
2 - Put JVM-specific classes and jars within /usr/lib/jvm-name
3 - Give each JVM (and all tools that invoke it) a script to append its
JVM-specific classes to the classpath. Also, make these scripts all call a
central classpath-builder script that would build a classpath of the
non-JVM-specific classes from: the CLASSPATH environment variable from the
user, from any "--classpath" parameters, and from anything found in
/usr/share/java (and, hopefully, anything in $HOME/java, too).
> * Maybe putting jvm implementation jars in /usr/share/java/$impl
> is the solution.
Well, to me, "share" means share, which the jvm-specific libs aren't meant
for. On the other hand, stuff in /usr/lib/appname usually contains most
resources used by any app on the system.
> Packages that proviedes similar functionality
> should then have the same name. like tools.jar could point
> to classes.zip (in jdk1.1).
Uhhhh. I don't know about this, Yogi! Different JVM's allocate their
functionality across different jar files, no? With JDK 1.0, everything was
in classes.zip or something. Nowadays, with Sun's JDK, they've got about 8
or 9 jar files.... and some have duplicate copies of classes. So, I wouldn't
worry about what individual JVM implementations name their private jars.
That's their problem. We just need to know them when we write the script
that builds the classpath and invokes them.
- Joe
Reply to: