This is the mail archive of the java-patches@sourceware.cygnus.com 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]

Re: _Jv_FindClass


Tom Tromey <tromey@cygnus.com> writes:

> In _Jv_FindClass I see this:
> 
> 	  // if "loader" delegateted the loadClass operation
> 	  // to another loader, register explicitly
> 	  // that he is also an initiating loader of the
> 	  // given class.  	  
> 
> 	  if (klass && (klass->getClassLoader () != loader))
> 	    _Jv_RegisterInitiatingLoader (klass, 0);
> 
> Shouldn't the second argument to _Jv_RegisterInitiatingLoader be
> `loader'?

It seems like you're right.

I don't remember the details, but here are some comments off the top
of my head.

Loader `NULL' represents the bootstrap loader, i.e. the non-existent
loader for the classes linked into the application.

Every class has a number of initiating loaders, and one of these is
the loader that actually did the loading (the defining loader).
Often, a class loader will delegate to the boot loader (in case of all
the linked-in classes), and thus the original loader needs to also be
registered.

The result of getClassLoader() is the defining loader.

The defining loader is implicitly an initiating loader, so it is not
explicitly registered in the table for initiating loaders in the GCJ
runtime. 


-- Kresten

 Kresten Krab Thorup           "I like my eggs ploded"
 Department of Computer Science, University of Aarhus
 Aabogade 34, DK-8200 Aarhus N, Denmark
 +45 8942 5665 (office), +45 2343 4626 (mobile)

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