This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
PR java/14070: gij and -jar argument should set the manifest Class-path recursively
- From: Andrew Haley <aph at redhat dot com>
- To: java-patches at gcc dot gnu dot org, classpath-patches at gnu dot org, avdyk at debian dot org
- Date: Mon, 1 Nov 2004 12:43:42 +0000
- Subject: PR java/14070: gij and -jar argument should set the manifest Class-path recursively
- References: <16770.23554.612624.978037@cuddles.cambridge.redhat.com>
Andrew Haley writes:
> This is quite tricky, because the "Class-Path" attributes have to be
> resolved relatively to the JARs in which they occur.
>
> Classpath dudes: sorry, this is relative to my branch and not
> Classpath mainline, but it should adapt easily enough.
>
> Andrew.
>
>
> 2004-10-29 Andrew Haley <aph@redhat.com>
>
> * java/net/URLClassLoader.java (JarURLLoader.classPath,
> JarURLLoader.extensionURLLoaders): new fields.
> (JarURLLoader.getExtensionURLLoaders): New method.
> (URLClassLoader.getURLLoader): New method broken out from addURLImpl.
> (JarURLLoader.JarURLLoader): Read mainfest to get "Class-Path"
> attribute.
> (JarURLLoader.getResource): Scan JARs in the "Class-Path".
I found an interesting bug in my solution. The "Class-Path" attribute
allows you to create circular dependencies, so you have to detect the
loop in order not to go into infinite recursion.
Does anoyone understand what other Java class libraries to do detect
such pathological cases? Somehow, even in a complex hierarchy of
class loaders it must be possible to detect the sitiation where one
delegates to another which delgates back to the first, etc, etc.
Andrew.