What is the difference between Class.forName() and ClassLoader.loadClass()?

Both methods try to dynamically locate and load a java.lang.Class object corresponding to a given class name. However, their behavior differs regarding which java.lang.ClassLoader they use for class loading and whether or not the resulting Class object is initialized.

The most common form of Class.forName(), the one that takes a single String parameter, always uses the caller's classloader. This is the classloader that loads the code executing the forName() method. By comparison, ClassLoader.loadClass() is an instance method and requires you to select a particular classloader, which may or may not be the loader that loads that calling code. If picking a specific loader to load the class is important to your design, you should use ClassLoader.loadClass() or the three-parameter version of forName() added in Java 2 Platform, Standard Edition (J2SE): Class.forName(String, boolean, ClassLoader).

Additionally, Class.forName()'s common form initializes the loaded class. The visible effect of this is the execution of the class's static initializers as well as byte code corresponding to initialization expressions of all static fields (this process occurs recursively for all the class's superclasses). This differs from ClassLoader.loadClass() behavior, which delays initialization until the class is used for the first time.

You can take advantage of the above behavioral differences. For example, if you are about to load a class you know has a very costly static initializer, you may choose to go ahead and load it to ensure it is found in the classpath but delay its initialization until the first time you need to make use of a field or method from this particular class.

The three-parameter method Class.forName(String, boolean, ClassLoader) is the most general of them all. You can delay initialization by setting the second parameter to false and pick a given classloader using the third parameter. I recommend always using this method for maximum flexibility.

Class initialization errors are tricky

Just because you successfully load a class does not mean there won't be any more problems. Recollect that static initialization code can throw an exception, and it will get wrapped in an instance of java.lang.ExceptionInInitializerError, at which point, the class becomes unusable. Thus, if it is important to process all such errors at a known point in code, you should use a Class.forName() version that performs initialization.

Furthermore, if you handle ExceptionInInitializerError and take measures so that the initialization can be retried, it will likely not work. This code demonstrates what happens:

public class Main
{
   public static void main (String [] args) throws Exception
   {
       for (int repeat = 0; repeat < 3; ++ repeat)
       {
           try
           {
               // "Real" name for X is outer class name+$+nested class name:
               Class.forName ("Main$X");
           }
           catch (Throwable t)
           {
               System.out.println ("load attempt #" + repeat + ":");
               t.printStackTrace (System.out);
           }
       }
   }
   private static class X
   {
       static
       {
           if (++ s_count == 1)
               throw new RuntimeException ("failing static initializer...");
       }
      
   } // End of nested class
   private static int s_count;
} // End of class

This code attempts to load the nested class X three times. Even though X's static initializer fails only on the first attempt, all of them fail:

>java Main
load attempt #0:
java.lang.ExceptionInInitializerError
       at java.lang.Class.forName0(Native Method)
       at java.lang.Class.forName(Class.java:140)
       at Main.main(Main.java:17)
Caused by: java.lang.RuntimeException: failing static initializer...
       at Main$X.(Main.java:40)
       ... 3 more
load attempt #1:
java.lang.NoClassDefFoundError
       at java.lang.Class.forName0(Native Method)
       at java.lang.Class.forName(Class.java:140)
       at Main.main(Main.java:17)
load attempt #2:
java.lang.NoClassDefFoundError
       at java.lang.Class.forName0(Native Method)
       at java.lang.Class.forName(Class.java:140)
       at Main.main(Main.java:17)

It is slightly surprising that the errors on subsequent load attempts are instances of java.lang.NoClassDefFoundError. What happens here is that the JVM has already noted the fact that X has been loaded (before the initialization is attempted), and the class cannot be unloaded until the current classloader is garbage collected. So, on subsequent calls to Class.forName(), the JVM does not attempt initialization again but, rather misleadingly, throws an instance of NoClassDefFoundError.

The proper way to reload such a class is to discard the original classloader instance and create a new one. Of course, this can be done only if you had anticipated that and used the proper three-parameter form of forName().

The hidden Class.forName()

I am sure you have used Java's X.class syntax to obtain a Class object for a class whose name is known at compile time. Less well known is how this is implemented at the byte-code level. The details are different across compilers, but all of them generate code that uses the one-parameter form of Class.forName() behind the scenes. For example, javac from J2SE 1.4.1 translates Class cls = X.class; into the following equivalent form:

    ...
       // This is how "Class cls = X.class" is transformed:
       if (class$Main$X == null)
       {
           class$Main$X = class$ ("Main$X");
       }
       Class cls = class$Main$X;
   ...
   static Class class$ (String s)
   {
       try
       {
           return Class.forName (s);
       }
       catch (ClassNotFoundException e)
       {
           throw new NoClassDefFoundError (e.getMessage());
       }
   }
   static Class class$Main$X; // A synthetic field created by the compiler

Of course, everything mentioned above about Class.forName()'s short form always initializing the class in question applies to X.class syntactic form as well. The details are different when such syntax is used to get Class objects for primitive and array types, and I leave that as an exercise for curious readers.

Fun with Sun's javac

In the previous example, you saw that the result of loading the class was cached in a special package-private static field artificially created by the compiler, and a synthetic helper method executed Class.forName(). The reason this is convoluted may be because the syntax used was unavailable in early Java versions, so the feature was added on top of the Java 1.0 byte-code instruction set.

Armed with this insight, you can have a bit of fun at the compiler's expense. Compile this tongue-in-cheek code snippet using javac from J2SE 1.3.1:

public class Main
{
   public static void main (String [] args) throws Exception
   {
       System.out.println ("String class: " + String.class);
       class$java$lang$String = int.class;
       System.out.println ("String class: " + String.class);
   }
  
   static Class class$java$lang$String;
} // End of class

If you run it, you will get the following, which is ridiculous at best:

>java Main
String class: class java.lang.String
String class: int

At least the compiler in J2SE 1.4.1 will reject the code above. But you can still fool it by setting the field reflectively:

    public static void main (String [] args) throws Exception
   {
       System.out.println ("String class: " + String.class);
       Main.class.getDeclaredField ("class$java$lang$String").set (null, int.class);
       System.out.println ("String class: " + String.class);
   }

So, next time you code the familiar Class.forName() incantation, you should know what it entails and what alternatives exist.

About the author

Vladimir Roubtsov has programmed in a variety of languages for more than 13 years, including Java since 1995. Currently, he develops enterprise software as a senior developer for Trilogy in Austin, Texas.