Re: A query on the classloader architecture

[Chris Gray]

On Friday 09 July 2004 02:15, David Holmes wrote:
> These are questions for the different VM implementors out there.

ObDisclaimer: the Wonka VM doesn't (currently) use Classpath, but ...

> 1. Is your bootstrap loader represented by null or an actual Classloader
> instance?

Null. (But see below).

> 2. Is your bootstrap loader and system/application classloader the same
> object?

No. 

The system classloader is created as soon as we have the infrastructure 
(Class, String, ...) to do it, and from then on it is responsible for loading 
classes from the bootstrap class path (only). All requests to load a class in 
java.* or wonka.* are dispatched to the system class loader, by-passing the 
class loader hierarchy.

The extension class loader is created only if java.ext.dirs.path exists. It 
loads classes from this path, and its parent is the system class loader.

The application class loader loads classes from -classpath/$CLASSPATH, and is 
responsible for loading the application specified on the command line. Its 
parent is the extension class loader if this exists, the system class loader 
otherwise.

> 3. Do you think your structure for the bootstrap and system loader
> correctly reflect the expectations of the security architecture.

As regards the above, yes. Dispatching java.* classes directly to the system 
class loader seems to be implied by some passages in the specs and/or Li 
Gong's book, but may actually be over-zealous; however I don't see how code 
could depend on a different behaviour. OTOH our handling of runtime packages 
is somewhat flakey; we are messing around matching strings when we should 
have a VM structure for the purpose.

The relationship between bootstrap loader and system class loader may change 
in the future. On the one hand, we currently "kill" the bootstrap loader as 
soon as the system class loader has been created, but it could be better to 
keep it around and have the system class loader delegate to it. (This would 
be essential if we wanted to store some classes in a "predigested" format, 
and not have to go through defineClass() to load them). On the other, it 
would be a useful simplification if classes loaded by the bootstrap class 
loader would later return the system class loader as their class loader.  It 
remains to be seen whether this can be done without creating too many 
bootstrapping problems. 

As Jeroen says, whatever you will do will "break" some B.A.D. code. I think 
that most code which depends on the system class loader being null will be in 
the "web crapplet" category, and Wonka doesn't really aim to be able to run 
all that stuff. For VMs which aim to do just that, this is going to be a 
major pain.

I don't think Classpath can legitimately mandate a particular answer to either 
(1) or (2). Based on the responses to this survey you could optimise for one 
case or another, but one day a VM will have excellent reasons to do things 
differently. Ideally the Classpath VM API should reflect this, so authors of 
"deviant" VMs only need to modify their VMclasses.

Best wishes

-- 
Chris Gray                      /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi        http://www.kiffer.be/k/
address@hidden                         +32 3 216 0369