Re: A query on the classloader architecture

[Chris Gray]

On Sunday 11 July 2004 13:18, David Holmes wrote:
> Chris,
>
> > It seems only one person is using "system class loader" to mean a
> > Java class which loads system classes, and that person is me.
> > I thought I'd got the terminology from Li Gong's book (which I don't
> > have handy), but apparently the rest of the world is unanimous in
> > using "system class loader" to mean the
> > application class loader. Sorry for the confusion.
>
> It is Sun's fault as they decided the class loader that loads the
> application is the "system class loader" while at the same time "core"
> classes in the java.* packages were referred to as "system classes" (which
> is what Li Gong calls them all the time) but are "loaded" by the bootstrap
> loader. These days I tend to say system/application classloader to refer to
> the class loader returned by getSystemClassLoader that loaded the
> application. :)

And then go to the bathroom to rinse your mouth with disinfectant. :)

> Does this mean you need to edit your previous email to me to clarify
> exactly which class loader you were referring to with each point?
I guess so, yes. Here goes ...

During bootstrapping, a native code (C) classloader is used to load the most 
fundamental classes; Object, Class, String, Thread, etc.. This classloader 
only searches one file, namely the first .jar or .zip in the bootstrap 
classpath (normally this is wre.jar). As soon as it is possible to run Java 
bytecode a Java bootstrap classloader is created, and this classloader 
inherits all classes loaded by the native code. The Java bootstrap class 
loader will load classes and system resources from the whole bootstrap class 
path (-Xbootclasspath). All requests to load a class in java.* or wonka.* are 
dispatched to the system class loader, by-passing the class loader hierarchy.

Classes which are loaded by the Java bootstrap classloader will return a 
reference to the Java bootstrap classloader as class.getClassLoader(). 
Classes which are loaded by the native code classloader will return null 
(this could change), as will primitive data types. We have not seen any 
problems resulting from this, but some code written to a Java 1.1 security 
model could fail if it assumes classloader null <=> system class.

The extension class loader is created only if java.ext.dirs.path exists. It 
loads classes from this path, and its parent is the (Java) bootstrap 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 (Java) bootstrap 
class loader otherwise.

Does that make more sense?

Best wishes

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