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.classinMainClassactually holds a reference to a physicalClassobject.
Probably because TestClass still exists, it’s just marked erroneous. It has been already loaded and verified.