extension directories

[Anthony Green]

I have some questions regarding extension directories...

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.

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.

The BouncyCastle RPM installs JRE versioned .jar files in directories
under /usr/share/java-ext.

Should java-gcj-compat set gij's java.ext.dirs to
$JAVA_HOME/lib/ext:/usr/share/java-ext ?

How do the proprietary JRE's pick up the contents
of /usr/share/java-ext?

How are any of JREs supposed to find the JPackage bouncycastle jar
files?

Thanks!

AG

[JPackage-discuss] extension directories

[David Walluck]

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

[JPackage-discuss] extension directories

[Anthony Green]

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

[JPackage-discuss] extension directories

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
> 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?

Yes.
> > 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 made my own rpm of bc 1.31. It's using ant now for the build, as they
fixed/added the files upstream in this past release.

Maybe I installed the jar into too many places.

There's an issue building sometimes for `build-test'. I don't udnerstand
since I am sure I have built this same version before. It's only
happening on gcj (not Sun) as far as I know, so it's something to look into.
> 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.

It seems we have to add this to be consistent.

- --
Sincerely,

David Walluck
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFDytWparJDwJ6gwowRAiUZAJsFJhL5HuTWfYqJYzxOUIuBJnQgbwCeJnL2
> RxyeB+FxmPWxCTtpe+OeeUU=
> =CC1P
> -----END PGP SIGNATURE-----

[JPackage-discuss] extension directories

[Anthony Green]

On Sun, 2006-01-15 at 18:07 -0500, David Walluck wrote:
> > 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.
>
> It seems we have to add this to be consistent.

Ok, here's my proposed patch.  Tom - what do you think?

--- java.c~	2006-01-15 15:51:43.000000000 -0800
+++ java.c	2006-01-15 15:51:49.000000000 -0800
@@ -1,5 +1,5 @@
-/* java.c -- set LD_LIBRARY_PATH, LD_PRELOAD and exec gij
-   Copyright (C) 2005  Red Hat
+/* java.c -- set LD_LIBRARY_PATH, LD_PRELOAD, java.ext.dirs and exec gij
+   Copyright (C) 2005, 2006  Red Hat

This file is part of java-gcj-compat.

@@ -40,6 +40,31 @@
 #include <string.h>
 #include <unistd.h>

+/* Return argv with -Djava.ext.dirs set properly, however, don't
+   change argv if -Djava.ext.dirs is already on the command line.  */
+char **
+set_java_ext_dir (int argc, char *argv[])
+{
+  char **nargv;
+  int i = 1;
+
+  while (i < argc && *argv[i] == '-')
+    {
+      if (strncmp ("-Djava.ext.dirs=", argv[i], 16) == 0)
+	return argv;
+      else
+	i++;
+    }
+
+  nargv = (char **) malloc ((argc + 2) * sizeof(char *));
+  nargv[0] = argv[0];
+  nargv[1] = "-Djava.ext.dirs=" JAVA_HOME "/jre/lib/ext:/usr/share/java-ext";
+  for (i = 2; i <= argc; i++)
+    nargv[i] = argv[i-1];
+  nargv[i] = 0;
+  return nargv;
+}
+
 int
 main (int argc, char* argv[])
 {
@@ -111,7 +136,7 @@

free (newpath);

-  error_code = execv (GCJ_BIN_DIR "/gij", argv);
+  error_code = execv (GCJ_BIN_DIR "/gij", set_java_ext_dir (argc, argv));

fprintf (stderr, "error spawning gij\n");

[JPackage-discuss] extension directories

[Thomas Fitzsimmons]

Hi,

On Sun, 2006-01-15 at 15:55 -0800, Anthony Green wrote:
> On Sun, 2006-01-15 at 18:07 -0500, David Walluck wrote:
> > > 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.
> >
> > It seems we have to add this to be consistent.
>
> Ok, here's my proposed patch.  Tom - what do you think?
>
> --- java.c~	2006-01-15 15:51:43.000000000 -0800
> +++ java.c	2006-01-15 15:51:49.000000000 -0800
> @@ -1,5 +1,5 @@
> -/* java.c -- set LD_LIBRARY_PATH, LD_PRELOAD and exec gij
> Copyright (C) 2005  Red Hat
>
> +/* java.c -- set LD_LIBRARY_PATH, LD_PRELOAD, java.ext.dirs and exec gij
> Copyright (C) 2005, 2006  Red Hat
>
> This file is part of java-gcj-compat.
>
> @@ -40,6 +40,31 @@
>  #include <string.h>
>  #include <unistd.h>
>
> +/* Return argv with -Djava.ext.dirs set properly, however, don't
> change argv if -Djava.ext.dirs is already on the command line.  */
>
> +char **
> +set_java_ext_dir (int argc, char *argv[])
> +{
> char **nargv;
> int i = 1;
> while (i < argc && *argv[i] == '-')
> {
>  if (strncmp ("-Djava.ext.dirs=", argv[i], 16) == 0)
> return argv;
>  else
> i++;
> }
> nargv = (char **) malloc ((argc + 2) * sizeof(char *));
> nargv[0] = argv[0];
> nargv[1] = "-Djava.ext.dirs=" JAVA_HOME "/jre/lib/ext:/usr/share/java-ext";

Should we still include /usr/share/java-ext?  That seems incompatible
since no proprietary JVM would include that directory.
> for (i = 2; i <= argc; i++)
> nargv[i] = argv[i-1];
> nargv[i] = 0;
> return nargv;
>
> +}
>
> int
>  main (int argc, char* argv[])
>  {
> @@ -111,7 +136,7 @@
>
> free (newpath);
> error_code = execv (GCJ_BIN_DIR "/gij", argv);
>
> error_code = execv (GCJ_BIN_DIR "/gij", set_java_ext_dir (argc, argv));
>
> fprintf (stderr, "error spawning gij\n");

Do we need a similar change in javac?

Tom

[JPackage-discuss] extension directories

[Anthony Green]

On Mon, 2006-01-16 at 12:06 -0500, Thomas Fitzsimmons wrote:
> > nargv = (char **) malloc ((argc + 2) * sizeof(char *));
> > nargv[0] = argv[0];
> > nargv[1] = "-Djava.ext.dirs=" JAVA_HOME "/jre/lib/ext:/usr/share/java-ext";
>
> Should we still include /usr/share/java-ext?  That seems incompatible
> since no proprietary JVM would include that directory.

What is the point of /usr/share/java-ext then?

BTW, there's a mistake in that patch...

+  nargv[1] = "-Djava.ext.dirs=" JAVA_HOME "/lib/ext:/usr/share/java-ext";
> Do we need a similar change in javac?

Maybe, although it's less critical since the extensions I care about are
security providers.

AG

[JPackage-discuss] extension directories

[Thomas Fitzsimmons]

On Mon, 2006-01-16 at 09:30 -0800, Anthony Green wrote:
> On Mon, 2006-01-16 at 12:06 -0500, Thomas Fitzsimmons wrote:
> > > nargv = (char **) malloc ((argc + 2) * sizeof(char *));
> > > nargv[0] = argv[0];
> > > nargv[1] = "-Djava.ext.dirs=" JAVA_HOME "/jre/lib/ext:/usr/share/java-ext";
> >
> > Should we still include /usr/share/java-ext?  That seems incompatible
> > since no proprietary JVM would include that directory.
>
> What is the point of /usr/share/java-ext then?

JPackage scripts search in /usr/share/java-ext when they're building a
classpath.  But the proprietary SDKs do not add /usr/share/java-ext to
their java.ext.dirs properties.  I'm not sure if JPackage developers
planned to do that somehow but it never happened, so I don't think we
should do it in java-gcj-compat.
> BTW, there's a mistake in that patch...
> nargv[1] = "-Djava.ext.dirs=" JAVA_HOME "/lib/ext:/usr/share/java-ext";
> > Do we need a similar change in javac?
>
> Maybe, although it's less critical since the extensions I care about are
> security providers.

OK, we can do this later if it turns out to be necessary.

Tom

[JPackage-discuss] extension directories

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
> 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.

I just tried the latest java-gcj-compat (62) rpm and are you suggesting
moving the bcprov jar there? Currently, if it's not in
/usr/share/java/gcj-endorsed, then gcj cannot find it. Note, this is
where jessie and gnu-crypto are already and bc is no different as far as
I can see.

Also, some of the symlinks in /usr/share/java/gcj-endorsed are
versioned, while others are not. What is the policy here?
> 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.

I am not sure what the specs say. In my updated package, I use only
%{_javadir}, so this becomes a non-issue. Remember, nothing ever used
the /usr/share/java-ext directory explicitly, so we never ran into the
issue, even on the proprietary stacks.

- --
Sincerely,

David Walluck
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFDzZ76arJDwJ6gwowRAsOzAJ9pkQB/wRakN9OgZ/tvxYEcNjtlSgCePUND
> r22Y2T9KvtmM7M2Ptv2RQfw=
> =Z2WF
> -----END PGP SIGNATURE-----

[JPackage-discuss] extension directories

[Anthony Green]

On Tue, 2006-01-17 at 20:50 -0500, David Walluck wrote:
> Anthony Green wrote:
> > 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.
>
> I just tried the latest java-gcj-compat (62) rpm and are you suggesting
> moving the bcprov jar there? Currently, if it's not in
> /usr/share/java/gcj-endorsed, then gcj cannot find it. Note, this is
> where jessie and gnu-crypto are already and bc is no different as far as
> I can see.

I'd like to suggest that we move all of these providers out
of /usr/share/java/gcj-endorsed and into the appropriate extensions
directory.  My understanding is that's where providers belong, and the
endorsed directories are reserved for packages within the special
endorsed namespaces.
> Also, some of the symlinks in /usr/share/java/gcj-endorsed are
> versioned, while others are not. What is the policy here?

No idea.

AG

[JPackage-discuss] extension directories

[David Walluck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
> I'd like to suggest that we move all of these providers out
> of /usr/share/java/gcj-endorsed and into the appropriate extensions
> directory.  My understanding is that's where providers belong, and the
> endorsed directories are reserved for packages within the special
> endorsed namespaces.

I don't know anything about that. If you are right, you will have to
repackage jessie and gnu-crypto. Then you can decide how to link into
that directory.

Also, I never actually tested what happens when you put bcprov into
lib/ext instead. The `make install' for java-gcj-compat didn't seem to
create this directory, though the actual code patch is in there.

- --
Sincerely,

David Walluck
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFDzcLjarJDwJ6gwowRAvdfAKCUgnvQWZZQQZeU8rZ9dwazvx4NLgCfQTr0
> rAT3IaKI356wKfMlgAD7BBs=
> =Yy+K
> -----END PGP SIGNATURE-----