Re: java library installation issues
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
Reply to: