Class.forName() debunked

Question

This issue is about: Dynamic loading and Inheritance.
Debugging an odd ClassNotFoundException in a J2EE Application, I was involved investigating deeply Class.ForName(). This method - namely the version with only the class name as parameter - is used inside xsdbeans.jar, an optiopnal library, shipped with IBM WebSphere 5.x. Moving the jar from the EAR classloader to the server runtime classloader caused weird behavior on my app.
I try to simplify the core question:
Suppose class E extends B. Base class B declares an instance method, dynLoad(String name) that uses internally Class.forName(String name).
Say 'e' an instance of E. Invoking e.dynLoad("Foo"), Class.forName("Foo") should use the ClassLoader of current class. But which is the 'current class': E or B? Is it the class of current object (E) or the declaring superclass (B)?
My instinctive answer was: E. But my J2EE app was behaving as the current class was B. Indeed E and B may be defined by different classloaders, and this makes a big difference.
A rapid lookup at Sun's docs confirmed my first hypothesis:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Class.html#forName(java.lang.String)
> Returns the Class object associated with the class or interface with the given string name.
Invoking this method is equivalent to:
Class.forName(className, true, currentLoader)
where currentLoader denotes the defining class loader of the current class.
ok, this is a little misleading, but going on:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Class.html#forName(java.lang.String,%20boolean,%20java.lang.ClassLoader)
> For example, in an instance method the expression:
>
Class.forName("Foo")
is equivalent to:
Class.forName("Foo", true, this.getClass().getClassLoader())
Not equivocal. The current class is the class of current object, no matter (apparently) if the instance method is declared in a superclass.
Right? Wrong. Here a minimal counter-example:
//-- B.java
import java.net.*;
public class B {
    public void dynLoad(String name) throws Exception {
        System.out.println(getClass().getSuperclass()
            + " defining classloader is: "
            + getClass().getSuperclass().getClassLoader());
        System.out.println(getClass()
            + " defining classloader is: "
            + getClass().getClassLoader());
        System.out.println("\n1) Class.forName(\""+name+"\");");
        // Loading with 'currentLoader'
        Class.forName(name)
            .newInstance();
        System.out.println("\n2) Class.forName(\""+name
            +"\", true, this.getClass().getClassLoader());");
        // This should be equivalent (by Sun J2SE API spec)
        Class.forName(name, true, this.getClass().getClassLoader())
            .newInstance();
    public static void main(String[] args) {
        ClassLoader syscl = ClassLoader.getSystemClassLoader();
        if (!URLClassLoader.class.isInstance(syscl)) {
            System.err.println("Cannot continue the trick.");
            System.exit(1);
        URL[] urls = ((URLClassLoader)syscl).getURLs();
        // Yet Another ClassLoader
        URLClassLoader yacl = new URLClassLoader(urls) {
            // Force Parent-last delegation policy to assure
            // demanded classes are defined by _this_ classloader
            public Class loadClass(String name)
                throws ClassNotFoundException {
                Class c = findLoadedClass(name);
                if (c == null) {
                    try {
                        // Simulate no visibility to base class to assure
                        // it is _not_ defined by this classloader too
                        if (name.equalsIgnoreCase("B")) {
                            throw new ClassNotFoundException();
                        c = findClass(name);
                    } catch (ClassNotFoundException e) {
                        c = getParent().loadClass(name);
                return c;
        try {
            // Loading class E with a different classloader
            Class c = yacl.loadClass("E");
            c.getMethod("dynLoad", new Class[]{String.class})
                .invoke(c.newInstance(), new Object[]{"Foo"});
        } catch (Exception ex) {
            ex.printStackTrace();
            System.exit(1);
//-- E.java
public class E extends B {
//-- Foo.java
public class Foo {
  public Foo() {
    System.out.println(getClass()
      + " defining classloader is: "
      + getClass().getClassLoader());
}Running above B.main() produce the following output on Sun JDK 1.3, 1.4.2, 1.5:
> class B defining classloader is: sun.misc.Launcher$AppClassLoader@3d200480
class E defining classloader is: B$1@3d2c0480
1) Class.forName("Foo");
class Foo defining classloader is: sun.misc.Launcher$AppClassLoader@3d200480
2) Class.forName("Foo", true, this.getClass().getClassLoader());
class Foo defining classloader is: B$1@3d2c0480
The evidence is that classloader used is not the same. in the case 1) it uses the classloader of superclass B. Hence the two form of Class.forName() invocation are not equivalent, as stated in Sun documentation.
Disclosure
The evidence is confirmed and explained looking at Sun's implementation of java.lang.Class.java and java.lang.ClassLoader.java: finally the Class.forName(String name) relies on sun.reflect.Reflection.getCallerClass(int) to find the famous 'current class' mentioned in the javadocs. This undocumented method returns the i-th caller class of current stack frames; each stack frame represents a method invocation coupled with its declaring class.
I wonder why in Sun docs this poorly explained issue was remaining immutable from 1.3 to date. Furthermore: which was the intended behavior? Another reason to the long said "Class.forName() is evil..." or am I missing something?
regards, Lorenzo

Answer 1

Of course, it comes down to the question: What is the current class?
Not something well defined. You are looking for this.getClass(), it's taking the class at compile time. If it went your way, woundn't that create an inconsistency in forName in static vs instance contexts?
Actually I think the static approach is more natural, because it means that forName behaves the way that resolving external references work. Your way would also go against the spirit of Java security policies which requires references down the classloader chain something to be treated with suspision.
The mechanism intended, I think, for these situations is the contextClassLoader property of Thread. When executing plugin type code the contextClassLoader should be set to the ClassLoader that loaded the plugin, and any references to resources or dynamic class loads from the plugin should be made using the contextClassLoader. This enables your shared library code to access classes and resources on behalf of the plugin code with access to classes and resources inside the plugin.
Thus, if you write library code or other container stuff likely to be called from a plugin you should probably always use:
Class cls = Thread.currentThread().getContextClassLoader().loadClass("foo");