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

[Andrew Pinski]

On Nov 1, 2004, at 7:43 AM, Andrew Haley wrote:

> Andrew Haley writes:
> > 2004-10-29  Andrew Haley  <address@hidden>
> >
> >         * 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,
Andrew Pinski