java library installation issues

Per Bothner
Mon Apr 2 23:17:00 GMT 2001

Egon Willighagen <> writes:

> 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....)

I hope not ...

> > 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?

Huh?  It is - all three.  I defined a *path* - a search order.

> 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...

But many Java packages are not programs, and in any case Java programs
depend on Java libraries.

The policy states that a package that installs a Java program must
install an executable in /usr/bin as an executable class or shell script.
But if the package can be built using gcj, then the executable should be
an actual executable.

> The directory /usr/share/java/gcj suggests some libraries of gcj, 
> not for use with gcj (just brainstorming...) What about /usr/share/java-gcj/ ?

No strong preference, but I weakly prefer /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...)

I'm not talking about executables here - I'm talking about libraries. 

> 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?

Ideally, I should like to see automake support for building the
executables (when a suitable configure option is given).  I've done
this (without taking much advantage of automake) for (the CVS version
of) Kawa: If you configure with --enable-gcj-compiled, it will use
'gcj -C' as the default for $JAVAC *and* it will build a kawa
executable, built using gcj, that can be installed in $prefix/bin.  If
you don't configure with --enable-gcj-compiled, then instead a kawa
shell-script wrapper will be installed in $prefix/bin.  My goal is to
encourage other Java packages to do the same.

> An second option is to have a system wide CLASSPATH set, that would
> include all jars... 

This violates the Policy, and I don't want to change this.  We cannot
require users to have to set their CLASSPATH in order to run Java

> > (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...

I don't understand this point.  Perhaps by "prevented" you mean
"made unnecessary".  (In which case note that that would be a non-standard
use of the word "prevented".)  If so, not I'm talking about installing
a real executable program compiled and linked by gcj.  In that case
you don't want to use a shell script if you don't need to.
	--Per Bothner

More information about the Java mailing list