Ok, it looks like my understanding of the details is lacking. I'll try to keep this message on a higher level. Sorry for any confusion.
On Tue, Apr 03, 2001 at 08:58:19AM -0700, Per Bothner wrote: > [EMAIL PROTECTED] (Andrew Pimlott) writes: > > 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. > > JNI libraries shold probably (by default) go in either /usr/lib > or /usr/lib/java. The latter again has the advantage of reducing > clutter and name clashes, but I don't know how awkward that would > be for other Java implementations. Ok, but what about the corresponding .class files? Do they just go in /usr/share/java ? I assume then that they contain enough information not to confuse non-JNI-supporting VM's? > Each compiler would only search a single /usr/share/java/$implementation > directory for jars. I.e. gcj would add /usr/share/java/gcj/*.jar and > /usr/share/java/*.jar to the path; kaffe would add > /usr/share/java/kaffe/*.jar and /usr/share/java/*.jar, etc. I guess I don't understand what could be in these directories that a compiler (at least a "normal" compiler) would need (for compiling, of course, not running). Why does the kaffe compiler need to see anything kaffe-specific when compiling "normal" Java code? > > 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. > > That's my point: There is no "standard" set of standard libraries. > The standard libraries of jdk, kaffe, and gcj are all different. > Jikes can work with any of them. Putting a symlink from > /usr/share/java/jdk1.3 (say) to /usr/share/java/jikes is one > solution, assuming jdk1.3 is installed. Better might be for > jikes to get installed as a shell script wrapper that picks > an available set of libraries. By standard, I meant the libraries defined by (a given version of) the Java platform. It should be possible, when compiling pure Java code with jikes, to say, I want to compile against the Java 2 platform, without saying anything about the specific VM I will use. > > 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, > > But the *default* is to search /usr/include at compile-time, and to > link with glibc. But all other libraries must be explicitly specified. > I want the default experience to be simple. > In Java we have a global namespace, so the user/developer should not > have to specify classpaths etc by default. The Java namespace may be better, but it is hardly global, with different versions of API's, and different implementations of the same API. > Of course it should be > possible to override classpaths to pick up specific versions, but > it is more important that the default be easy. Well, the questions is, does it have to be easier (less explicit) than in C? I fear that doing more automatically may lead to subtle problems (eg, different implementations of the same API in the classpath getting in each other's way). > One idea is that /usr/share/java (and /usr/share/java/$implementation) > can contain multiple versions of a library, and a compiler should > serach the appropriate one. A rough algorith: Sort the list of > *.jar files names. If there is both a XXX.jar and one or more XXX-NNN.jar, > pick XXX.jar. Typically XXX.jar will be a symlink t teh "preferred" > version. Similarly, if there are XXX-MM.jar and one or more XXX-MM-NN.jar, > pick XXX-MM.jar. I know that was only a first stab, but it would be nice to have a way to specify the default implementation of an API. For example, a directory /usr/share/java/defaults that contains symlinks to /usr/share/java with names like servlet.jar; .jar files in this directory would be first in the classpath. > When compiling a Java application to native code, the executable should > preferably be a native program. Requiring an extra shell wrapper > is just extra clutter and overhead. Sure--but by that point, you've already picked a VM. This raises the next question: into which forms should Debian packagers compile Java code? Andrew
