> 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
