-----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(a)zarb.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDys5TarJDwJ6gwowRAi6SAJ4lsKv8sUjzDILAXt9jSE+4cJcLnQCeIliF
JQYDqTI4XEA88JEeVO9yN3U=
=Neta
-----END PGP SIGNATURE-----