[jsr-291-eg] Use of the system classloader
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.
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.
where 'this' in 3. refers to the class doing the work in the library in
My own attempt to answer some;
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