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/ [EMAIL PROTECTED] +32 3 216 0369 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
