Why NoClassDefFoundError caused by static field initialization failure?

Question

Here is a interesting java question.

the following simple java program contains static field initialized by a method statically. Actually, I force the method which calculate the intiailize value to raise a NullPointException, When I access such a static field, a NoClassDefFoundError will raised. it seems the VM treat the Class is not complete.

But when I access the Class, it still available;

Does anyone knows why?

class TestClass {
    public static TestClass instance = init();

    public static TestClass init() {
       String a = null;
       a.charAt(0); //force a null point exception;
       return new TestClass();
    }
}

class MainClass {
    static public void main(String[] args) {
       accessStatic(); // a ExceptionInInitializerError raised cause by NullPointer
       accessStatic(); //now a NoClassDefFoundError occurs;

       // But the class of TestClass is still available; why?
       System.out.println("TestClass.class=" + TestClass.class);
    }

    static void accessStatic() {
        TestClass a;

        try {
            a = TestClass.instance; 
        } catch(Throwable e) {
            e.printStackTrace();
        }
    }   
}

Answer 1

The answer to such questions is usually buried somewhere in the specs... (§12.4.2)

What happens when classes are initialized:

Steps 1-4 are somewhat unrelated to this question. Step 5 here is what triggers the exception:

5. If the Class object is in an erroneous state, then initialization is not possible. Release the lock on the Class object and throw a NoClassDefFoundError.

6-8 continue the initialization, 8 executes the initializers, and what usually happens is in step 9:

9. If the execution of the initializers completes normally, then lock this Class object, label it fully initialized, notify all waiting threads, release the lock, and complete this procedure normally.

But we got an error in the initializer so:

10. Otherwise, the initializers must have completed abruptly by throwing some exception E. If the class of E is not Error or one of its subclasses, then create a new instance of the class ExceptionInInitializerError, with E as the argument, and use this object in place of E in the following step. But if a new instance of ExceptionInInitializerError cannot be created because an OutOfMemoryError occurs, then instead use an OutOfMemoryError object in place of E in the following step.

Yep, we see an ExceptionInInitializerError b/c of the null pointer exception.

11. Lock the Class object, label it erroneous, notify all waiting threads, release the lock, and complete this procedure abruptly with reason E or its replacement as determined in the previous step. (Due to a flaw in some early implementations, a exception during class initialization was ignored, rather than causing an ExceptionInInitializerError as described here.)

And then the class is marked erroneous which is why we get the exception from step 5 the second time.

---

The surprising part is the third printout which shows that TestClass.class in MainClass actually holds a reference to a physical Class object.

Probably because TestClass still exists, it's just marked erroneous. It has been already loaded and verified.