getClassLoader()

[Godmar Back]

 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 
    class loader. 

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 
use it.

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?

	- Godmar