-----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.
> 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.
> 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...
So the question is, is gcj really using /usr/share/java/gcj-endorsed in
addition to $(jardir)-ext? I am not so sure.
> Should java-gcj-compat set gij's java.ext.dirs to
> $JAVA_HOME/lib/ext:/usr/share/java-ext ?
I think so.I have been aware of this issue for some time. I have always
done with in the gcc spec:
# Fix java-ext path
sed -i -e 's,\$(jardir)/ext,$(jardir)-ext,g' libjava/Makefile.{am,in}
> How do the proprietary JRE's pick up the contents
> of /usr/share/java-ext?
It could very well be that they don't. At least there are no
$JAVA_HOME/lib/ext dirs that I see, if that's where they look.
> How are any of JREs supposed to find the JPackage bouncycastle jar
> files?
It turns out that for most cases you do not need a signed provider or
anything and you can just put it on the classpath.
In gcj's case, it does, in fact, pick it up through the class in
/usr/lib/security/classpath.security even when not explicity on the
classpath (by using the ext dirs mechanism).
- --
Sincerely,
David Walluck
<david@xxxxxxxx>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDys5TarJDwJ6gwowRAi6SAJ4lsKv8sUjzDILAXt9jSE+4cJcLnQCeIliF
JQYDqTI4XEA88JEeVO9yN3U=
=Neta
-----END PGP SIGNATURE-----
