即使 class 文件丢失或有错误，在第一次主动使用此 class 之前，预加载 class 不会报告错误？

Question

I was reading the article below and had a question about the following passage:

The jvm specification allows a class loader to preload a class when it expects it to be used,If encountered during preloading.class file is missing or has errors,The class loader must report a linkerror when the program first actively uses the class. If this class has not been actively used by the program,Then the class loader will not report an error.

Given the following code:

public class MyTest1 {
    public static void main(String[] args) {
            System.out.println(MyChild1.str); 
    }
}

class MyParent1 {
    public static  String str = "hello world";
    static {
        System.out.println("MyParent1 static block");
    }
}
class MyChild1 extends MyParent1 {
    public static String str2 = "welcome";
    static {
        System.out.println("MyChild1 static block");
    }
}

The operation result is:

MyParent1 static block
hello world

MyChild1 is not used actively but is loaded.

[Loaded com.yc.test.classloader.MyParent1 from 
file:/C:/Users/nhn/IdeaProjects/demo/out/production/demo/]
[Loaded com.yc.test.classloader.MyChild1 from 
file:/C:/Users/nhn/IdeaProjects/demo/out/production/demo/]

But when I run the code above after removing the class file of MyChild1, NoClassDefFoundError occurred.

Exception in thread "main" java.lang.NoClassDefFoundError: com/yc/test/classloader/MyChild1
    at com.yc.test.classloader.MyTest1.main(MyTest1.java:5)
Caused by: java.lang.ClassNotFoundException: com.yc.test.classloader.MyChild1
    at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
    ... 1 more

The operation result contradicts with the passage. Why?

https://www.tutorialfor.com/blog-228663.htm

Answer 1

This cited article is wrong, even with these undefined terms like “preload” and “when the program first actively uses the class”.

If “preload” is supposed to mean eagerly resolving referenced classes, we can refer to the Java Language Specification, §12.1.2. :

An implementation may resolve symbolic references from a class or interface that is being linked very early, even to the point of resolving all symbolic references from the classes and interfaces that are further referenced, recursively. (This resolution may result in errors from these further loading and linking steps.)

It then states about the potential errors:

The only requirement on when resolution is performed is that any errors detected during resolution must be thrown at a point in the program where some action is taken by the program that might, directly or indirectly, require linkage to the class or interface involved in the error. Using the "static" example implementation choice described above, loading and linkage errors could occur before the program is executed if they involved a class or interface mentioned in the class Test or any of the further, recursively referenced, classes and interfaces.

So it's definitely wrong to say that loading or linkage errors were only reportable “when the program first actively uses the class”, even when the article didn't care to explain what constitutes an active use.

As explained in this answer , initialization is performed under well defined conditions and the behavior of your program is understandable when overcoming the common confusion of loading and initialization . To evaluate the expression MyChild1.str , loading of the class MyChild1 is unavoidable and only after the class has been loaded, it is possible to determine that it doesn't have a field str but a superclass that has. So while it will be unavoidably loaded it will not get initialized , as neither of the specified actions (like the access to a static field) has been performed.

As you can recognize from your stack trace, the NoClassDefFoundError has been thrown right before evaluating the expression MyChild1.str , which is already as lazy as possible. Valid places to throw the error would have been the beginning of the method's execution, the loading and resolving of the Mytest1 class, or, as the linked part of the specification says, even before the execution of the entire program starts.

While the point of loading and resolving and hence, the point of throwing the error, is left to the particular implementation, all valid implementations will agree in throwing the error before coming to evaluate the expression MyChild1.str .