[jsr-291-eg] Use of the system classloader

Niclas Hedhman niclas at hedhman.org
Sun Aug 20 05:13:19 EDT 2006

On Tuesday 15 August 2006 18:01, Andy Piper wrote:
> This service makes it possible to register URL handlers from
> OSGi bundles, so that there's a way to load them other than by
> putting them in the system class path.

Not sure what you have in mind here, actually.

Never the less; 
The issue being brought to the table revolves around various classloading 
flaws in existing systems that we often want to leverage, and whether those 
can be dealt with to a reasonable extent.

 1.  Class.forName(c)
 2.  ClassLoader.getSystemClassLoader().loadClass(c)
 3.  Thread.currentThread().getContextClassLoader().loadClass(c)
 4.  this.getClass().getClassLoader().loadClass(c)
 5.  Correct extraction of the caller's class from the callstack
     followed by the use of the caller's classloader.
 6.  Incorrect extraction of the caller's class and reverting to
     the system classloader if failing.

(possibly others)

where 'this' in 3. refers to the class doing the work in the library in 

My own attempt to answer some;

 1.    Class.forName(c) 
    essentially calls 
       Class.forName( c, true, getCallerClassLoader() )
    but without the security checks (why?) so it is a matter of issue 5,
    at least for JDK1.5

 2. There are two concerns here I guess; 
     a. Code that correctly limit the loading to the system classloader.
     b. Code that incorrectly use the system classloader.
    And would we need the ability to distinguish the two??
    IIRC, it is possible to specify a system classloader at JVM start time,
    and perhaps this is something we could consider.

 3. This is probably the most common way nowadays. Leave it out of the
    discussion for now.

 4. This is often just bad code, not understanding that multiple classloader
    exists. In our context, it is not as bad and depends on whether
    Imports can be established at bundle time.

 5. In many places in the Sun JVM/JDK the callers class and classloader is
    extracted from the call stack. Should be no problem with this.

 6. In at least one place in the Sun JDK, the caller's class is attempted to 
    be extracted, but misses it by one level (probably due to insertion of
    an extra level of method) and instead hits the boot classloader, which
    would result in a NPE, so a fallback to system classloader is done at this
    point. This therefor becomes an issue 2.
    (The location I am referring to is the resolution of URL handlers, via the
    java.protocol.handler.pkgs system property. Sun says it won't fix the bug,
    due to unknown security repercussions.)

IMHO, it would be great if JSR-291 would be very specific on classloader 
issue, to increase the success ratio of leveraging existing packages out 
there. Potentially, this could also go as far as a standardized hook into the 
framework boot sequence, to allow complex cases to be resolved in an 
implementation independent way. I think this would smoothen adoption of 
JSR-291 technology in for instance projects like Geronimo.


More information about the jsr-291-eg mailing list