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