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]

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


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.


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