Re: PR java/14070: gij and -jar argument should set the manifest Class-path recursively

[Andrew Haley <aph at redhat dot com>]

Andrew Pinski writes:
 > 
 > On Nov 1, 2004, at 7:43 AM, Andrew Haley wrote:
 > 
 > > Andrew Haley writes:
 > >> 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.
 > 
 > This comes up with shared libraries with recursive dependencies.  What
 > most dynamic loaders do, is make a hash table to store which shared
 > library is already loaded and add them right before loading them and
 > then only load the ones which are not in the hash table.

Thanks.  I'm not sure that would work in this case, because we have
multiple class loaders that delegate to each other.

Andrew.