On Sun, 2006-01-15 at 17:36 -0500, David Walluck wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Anthony Green wrote:
> > gcj currently looks in /usr/share/java/ext for extensions, which isn't
> > compatible with JPackage. In fact, this directory doesn't exist in FC.
>
> This doesn't follow the JPackage spec if that's the idea. IMO, it should
> be changed upstream.
I suppose we could do that.
> > In JPackage-land, it looks like each JRE will have their own extensions
> > directory under $JAVA_HOME/lib/ext, and then there's the JPackage
> > maintained one at /usr/share/java-ext.
>
> I don't think that's quite right on the JPackage side, as at least I
> don't see any $JAVA_HOME/lib/ext directories.
I meant $JAVA_HOME/jre/lib/ext, like...
/usr/lib/jvm/java-1.5.0-sun-1.5.0.03/jre/lib/ext
Isn't that where JRE specific extensions should go?
> > The BouncyCastle RPM installs JRE versioned .jar files in directories
> > under /usr/share/java-ext.
>
> And also under /usr/share/java-%{version}, and also under
> /usr/share/java/gcj-endorsed...
Oh, really? Not in the version I'm using.
I don't think gcj-endorsed is the right place for this. In theory this
should only contains .jar files for classes in the blessed endorsed
namespace. The bouncycastle jar files should go in java.ext.dirs.
Should gcj be searching java.ext.dirs recursively? It doesn't do that
today, but from the way bouncycastle is installed, I'm guessing it
should.
> So the question is, is gcj really using /usr/share/java/gcj-endorsed in
> addition to $(jardir)-ext? I am not so sure.
It currently reads /usr/share/java/gcj-endorsed, but not $(jardir)-ext.
If we only need to have it look in $(jardir)-ext, then we can probably
submit a patch upstream to gcc.
If we also want it to look
in /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/ext then we should
probably do this has a java-gcj-compat hack.
AG
