My background in these issues is modest, but I have a strong interest in seeing them resolved, so let me try to add something.
On Mon, Apr 02, 2001 at 05:43:55PM -0700, Per Bothner wrote: > So where should be put the .jar files? I suggest leaving this as > /usr/share/java. However, we should add Java-implementation > sub-directories. What recommendation should we make to packagers of libraries that have native components? I assume that Java native method APIs (like JNI) are source-level, not binary-level. Thus one should expect compiled native code libraries to work on only one implementation, right? In that case, should we recommend that packagers compile such libraries against as many implementations as feasible? (I'm assuming that some implementations besides Sun's even use JNI, which could be mistaken.) On the other hand, if JNI is an ABI, it would be nice to put compiled libraries somewhere where they would be found by all compatible implementations. > So to summarize: The builtin search path should be (in this order): > (1) each .jar file in /usr/share/java/$implementation > (2) each .jar file in /usr/share/java > (3) the /usr/share/java directory itself This is plausible for the VM (but see below), but not the compiler. To my understanding, the compiler should not need to see the native parts of libraries to compile against them; the .class files should be sufficient. But having the compiler search all of the $implementation directories doesn't seem right. Perhaps a /usr/share/java/compiler or /usr/share/java/include directory containing just "header" files--ie, skeleton .class files--for libraries with native components? At very least, there needs to be a way for compilers not associated with a particular java implementation (eg jikes) to find the standard libraries. I'm sure gjc reqires some considerations that I missed above. I plead ignorance. > I've left out versioning issues. If one want to support multiple > versions of the same library one could install LIBRARY-VERSION.jar, > and install a symlink from LIBRARY.jar, but having compilers and > VMs pick the right version is unclear to me. This immediately points out a serious drawback to putting /usr/share/java/*.jar in the classpath automatically. Another drawback is the existence of multiple implementations of some APIs. I conclude that we should not not automatically put *.jar in the classpath. In C, the user specifies which libraries he wants to use at compile time, and the executable desclares the libraries (including versions) it wants to use at run-time. What is wrong with this model for Java? Java executables should, in general, be wrappers (probably shell scripts) that specify the needed libraries in an implementation-independent way, then run something like "java -Dfoo=bar class". All implementations should take the list of needed libraries from the wrapper, plus user-overrides (which should also be specified in an implementation-independent way), and try to run. Of course, the implementation for which the user has "java" selected by his $PATH is the one that should be used. Andrew