Re: java library installation issues
andrew@pimlott.ne.mediaone.net (Andrew Pimlott) writes:
> > 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 ?
Yes.
> I assume then that they contain enough
> information not to confuse non-JNI-supporting VM's?
I don't see that as an issue. If a Java package has native methods
written in JNI, then the VM better support JNI if the package is
going to work under it.
> 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?
The kaffe compiler (I don't think they actually have their own compiler)
needs to see all the standard java.* classes. It will have its own
implementation, different from Sun's or Gcj's. Now if we're compiling
to bytecode, it normally shouldn't matter which libraries are used,
assuming they are compatible. However, it obviously matters at
run-time (different imlementations will implement different methods
as mative, may implement different private fields and methods, etc).
Amd it matters when compiling to native code: Gcj generates code
for a Java class the same way it does for a C++ class. (That is the
point of CNI.) So order and alignment of fields (including private
fields) matters. Gcj for consistency we should use the same .jar
file whether compiling to native or to bytecodes. However, Sun's
javac should of course use their own .jar file.
> 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.
Remember we are talking about Free Software solutions. There is
no such thing as a Free Java 2 platform, so "standard" is not a
useful measure. You choose between a non-free "complete" version
("complete" because the "standard" is defined by Sun's implementation)
or a free non-complete version.
> > 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 consider that a bug, not a feature. There is no reason a user
needs to keep track of which of -lX11 -LXawt -lcurses -ltermcap -lgtk
-lm -ldns are needed on a given platform.
> > 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.
That is handled to some extent by different $implementation-s. In any
case, once a given java implementation is installed, I want the user
(or their Makefile) to not have to fiddle with classpaths and library
paths. That is the main purpose of this proposal.
> Well, the questions is, does it have to be easier (less explicit)
> than in C?
But it should.
> 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).
That's a integration bug. We will always risk that. However, if
I install one or more java implementation and one or more java
packages from some distribution CD, I should have the right to
expect that things will be consistent. That is my goal to
make that possible. It is better for the default to be consistent
thn to expect Jow Random Developer to have to manage all kinds of
versions.
> 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?
Well, my preference is: portable (.jar) + (when possible) gcj native.
Gcj is part of the standard GNU Compiler Collection. It is copyright
FSF, and (as part of Gcc) it is managed by a steering committee on
behalf of the FSF. It is GPL'd, but with a liberal license for run-time
code (non-viral even for embedded systems). It strives to be a
complete Java implementation, including an interpreter (and JIT could
be added), compiling to both native and .class files, JNI support,
debugging with gdb, compatibility and integration with other GNU
languages, and quickly growing maturity of libraries. As I said
before, I am surprised and disappointed that the Free Software
community has not supported Gcj better, but I think it may have
reached enough "critical mass" that more people will start using it.
(The Gcc 3.0 release should help.)
--
--Per Bothner
per@bothner.com http://www.bothner.com/~per/
Reply to: