Re: java library installation issues
Op dinsdag 03 april 2001 02:43, schreef Per Bothner:
> I'd like to make some progress on standard Linux/GNU installation
> standards for Java, and how GCJ fits into this.
Have you taken over the maintainership? (Just wondering....)
> This could lead to an updated Debian Java policy (which is
> at http://people.debian.org/~bortz/Java/policy.html) and ultimately
> be part of a future Linux File Hierarchy Standard.
Inclusion in FHS would indead be nice.
> 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
Is assume the latter is the "repository" version?
Why does it need to be one of these? Why not both, like in the
current place? The current policy also states that each Java program needs
to have an executable in /usr/bin... This exec can figure things out,
escpecially with its preknowledge...
> 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.
Versioning of jars is very important to me. It currently is not in the
Java policy, but i would love to see that happen.
I like your proposol. I am not sure wath Debian policy says about
linking, but i can imagine that the link will also point to the most recent
release... Since we want to move forward... and that if applications need
an older version, they (the /usr/bin/exec) should classpath the old
library itself...
> Now on to Gcj. For a package or application to "support" Gcj,
> its build procedure should build both a .jar and a pre-compiled
> .so file, and install both. The .jar file should be installed
> in /usr/share/java unless it depends on Gcj. If there can be
> a version that is gcj-specific or -optimized, it should be in
> /usr/share/java/gcj.
The directory /usr/share/java/gcj suggests some libraries of gcj,
not for use with gcj (just brainstorming...) What about /usr/share/java-gcj/ ?
> For example, the library could be configured
> to not use AWT when running on Gcj. In that case the generic
> version would be installed in /usr/share/java and the AWT-less version
> in /usr/share/java/gcj.
This does not directly makes sense to me.... Ok, i agree that gcj is not
"finished" yet, and that gcj does not support AWT yet. But do we want to
have several versions of one executable? (Not voting against, i would like
to see the same for libraries...)
What about naming of /usr/bin/exec then? I would propose /usr/bin/exec
and /usr/bin/exec-gcj...
> Where should .so be installed? The obvious location is /usr/lib.
> However, I'm wondering whether it might be better to separate out
> Java libraries in a separate directory for two reasons:
> (1) reduce clutter in /usr/lib
> (2) reduce risk of library name clashes.
> So I would suggest /usr/lib/gcj for .so files. In that case the
> gcj command should add /usr/lib/gcj to the list of directories to
> search at run-time, with an ld -rpath command.
>
> The final piece of magic I suggest: When the compiler compiles
> a Java class A and emits a reference to a class B (the class
> itself, a static method, or a static field of B), and B was
> found in L.jar in the builtin search path, then the compiler
> should check if there is a file /usr/lib/gcj/L.so. If so,
> it should emit whatever magic is needed s that the linker
> searches L.so (at both ld and run-time-linke times).
Sounds interesting... Could we build a meta-script that can generate
/usr/bin/exec and /usr/bin/exec-gcj and solve these dependencies
while auto-generating these executables?
> With this setup:
> (1) All Java compilers and VMs can compile find all "installed" .jars,
> without users having to fiddle with classpaths.
An second option is to have a system wide CLASSPATH set, that would
include all jars...
> (2) Java applications compiled with gcj automatically find the
> necessary ,so files, without the users having to explicitly list
> them on the gcj command line.
This is prevented by use of /usr/bin/exec scripts... (e.g. /usr/bin/ant)
Thus prevening user to fiddle with command line/classpath options...
Egon
Reply to: