gback at cs.utah.edu
Mon Jul 27 21:57:38 PDT 1998
Okay, here's the story:
Prior to JDK 1.2beta4, getClassLoader() would return null if the class
was loaded by the so-called "system loader".
Starting from JDK 1.2beta4, getClassLoader() can return a non-null class
loader in that case. The doc now says:
Returns the class loader for the class. Some implementations may use
null to represent the bootstrap class loader. This method will return
null in such implementations if this class was loaded by the bootstrap
This is used in Sun's new application class path loading scheme with
delegating class loaders.
Sun says further: http://java.sun.com/products/jdk/1.2/compatibility.html
Beginning with version 1.2 Beta 4 of the JDK software, application
classes are loaded by an actual ClassLoader instance. This makes it
possible for application classes to use installed extensions and also
separates the application class path , which is specified by the user,
from the system class path, which is fixed and should not be modified
by the user. The -Xsysclasspath option can still be used to override
the system class path if necessary.
Some applications that create their own security managers or class
loaders might not work under the new launcher. This is partly because
they make assumptions about class loaders that are no longer valid when
the application itself is started in a class loader. Those applications
can be updated for 1.2 to use the new security and class loader design,
or they can be run with the 'oldjava' command which supports the
old-style launcher that loaded everything from the system class path.
The 'oldjava' command does not support the extension mechanism or
the -jar option for executible JAR files.
See the extension mechanism specification for more information
regarding the new extension mechanism and its effect on class
loading. The document provides relevant information regarding the
new class loader delegation model and class loader API changes.
In Kaffe, the story is as follows:
Prior to 1.0b1, getClassLoader() would return null as the 1.1 spec demands.
The original 1.0b1 release returned a non-null class loader (interestingly,
that was before Sun published their API change in 1.2beta4!) because Tim's
opinion is that application usually just want to get the class loader and
Unfortunately, this change broke existing applications (except "Bar",
of course ;-) that make non-trivial use of class loaders, namely
Cornell's jkernel. So I convinced Tim to undo the change and return null.
I think the current plan is to wait until we a) have a more complete
implementation of 1.2's class loading scheme, including delegating class
loaders and b) the applications we care about have been updated to work
with the new scheme.
Thanks for the pointer to Bracha's paper. So, did he design the new
delegating class loader paradigm in 1.2?
More information about the kaffe