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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
