Re: java library installation issues

[egonw <egonw at subdimension dot com>]

Quoting Per Bothner <per@bothner.com>:
> > 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?
>
> Yes.
>
> > 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.

Ok, in addition to the current Debian policy, a third, preferred
option, being the gcj compiled library.


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

Indeed. But the principle holds that in Debian, with dependencies, that
a certain executable exactly knows where to find a certain library.
The build and run dependencies basically refer to an other package of
which the file structure is determined. Once a maintainer changes this
dir structure and thus file locations it possibly breaks many packages...
This is why policies are so important.


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

My point is that in /usr/share/java/gcj it seems to refer to libraries
used for gcj, instead of libraries compiled with gcj. Like in 
/etc/some-program, where settings are placed for a certain program.


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

Sorry. I was not completely clear in what i wanted to say. The library
would have the same functionality, with and without AWT (for example).
So the same holds for a certain application that uses this library.

A certain program that normally uses AWT, but wants to use the gcj
compiled version, has to fall back to non-AWT. This would indeed mean
that only one binary would suffice...

Now comes the reason why i failed to respond correctly to the issue;
How does a Java program (in Java byte code), use a gcj compiled
library? 

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

Do you mean that in order to use gcj compiled libraries the program
itself has to be gcj compiled as well?

Ok, i think i begin to see what you're aiming at...

Given Java source code that compiles with gcj to architecture-specific
code, you would make it (Debian) policy to compile with gcj in order
to use the gcj compiled libraries?
Or maybe, to have two conflicting packages program and program-gcj?
Preferably, based on the same source code, to prevent forking...

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

No, actually a meant prevent... i do not just want it unnecessary, but
the user should not have to use commandline options at all... and by
means of the policy prevent that this will ever be necessary.


Egon


--------------------------------------
FREE ANONYMOUS EMAIL!  Sign up now.
http://www.subdimension.com/freemail