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



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,
Andrew Pinski


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