This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Tom Tromey writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > Andrew> Does anoyone understand what other Java class libraries to do detect
 > Andrew> such pathological cases?  Somehow, even in a complex hierarchy of
 > Andrew> class loaders it must be possible to detect the sitiation where one
 > Andrew> delegates to another which delgates back to the first, etc, etc.
 > 
 > The only way to get a class loader delegation loop is to write a
 > custom class loader that has its own delegation approach.  The
 > standard class loaders only delegate to their parent, and the parent
 > is set by the constructor and is private.
 > 
 > Eclipse 2 had a class loader that could potentially get into
 > delegation loops.  As I recall it solved this problem by having a flag
 > that was set so it could tell when a circular call occurred.
 > 
 > In the Class-Path case, it probably suffices to keep a set of all seen
 > URLs, then stop when you see one for a second time.  I think this will
 > work fine as all the action is taking place inside of a single
 > URLClassLoader.

Okay, I think I see.  So, at entry to the URLClassLoader you create a
hash table and then when you're looping around all the sub-loaders you
check the hash table to see where you've been.  I'll try it.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]