Deep Java Virtual machine learning-the loading mechanism of classes (iii)

The initialization time of the class

In the previous article, we talked about six active uses of classes, one of which is reflection (class.forname ("Com.jack.test")), It is important to note that when you load a class by calling the LoadClass method of the Clasloader class, it is not an active call to the class and does not cause the initialization of the class.

So then I'll continue to give you 2 examples, let's see what their execution results are, and see if you can guess right?

 Public class test2{    publicstaticvoid  main (string[] args)    {        System.out.println (finaltest2.x);    }} class finaltest2{    publicstaticfinalint x=6/2;     Static {        System.out.println ("I am a final X");}    }

 Public class test2{    publicstaticvoid  main (string[] args)    {        System.out.println (finaltest2.x);    }} class finaltest2{    publicstaticfinalint x=new Random (). Nextint ();     Static {        System.out.println ("I am a final X");}    }

Is it surprising to see the results, 2 code looks almost identical, and is static modified, why and the previous article is not the same, why the first demo inside the static block did not execute it? Let's take a series of questions to solve the problem.

Explain

If you are careful you can see a final modifier, yes, the result is that it works.

public static final int X=6/2; this line of code, the Java virtual machine can know at compile time what the value of X, so at the compile time has put 3 in the constant pool , So when called in the Main method, the initialization of the class is not triggered,  i.e. the x at this time is the constant at compile time.

public static final int x=new Random (). Nextint ();  The x in this line of code does not determine a specific value at compile time, it needs to wait until it is run to determine the value of x, so the initialization of the class is triggered at run time, where x is the compiler's variable

Interface and Parent class

The 7 ways in which the class is actively loaded, all of which are the case of a single class, Let's talk about the next interface and the parent class

When a Java Virtual machine Initializes a class, all of his parent classes are required to be initialized, but if this class implements an interface, then:

1. When initializing a class, the interface it implements is not initialized first
2. When initializing an interface, it does not initialize its parent interface first

Therefore, a parent interface is not initialized because of his sub-interface or the initialization of the implementation class. The initialization of the interface is only caused when the program first uses his static variable.

Active use of a class or interface can be considered only if the static variable or static method accessed by the program is indeed defined in the current class or in the current interface. What do you mean by this sentence? Now let's take a look at this demo.

 Public classtest3{ Public Static voidMain (string[] args) {System.out.println (child.x); }}classparent{ Public Static intX=3; Static{System.out.println ("This is a parent"); }}classChildextendsparent{Static{System.out.println ("This was a child"); }}

 Public classtest3{ Public Static voidMain (string[] args) {System.out.println (child.x); }}classparent{ Public Static intX=3; Static{System.out.println ("This is a parent"); }}classChildextendsparent{ Public Static intX=3; Static{System.out.println ("This was a child"); }}

The above two examples are also the same line of code, the result is very different, one child has been initialized, the other is not.

Parental delegation Model

The class loader is used to load the class into the Java virtual machine, starting from the JDK1.2 version, the class loading process adopts the parental delegation model mechanism, which can better ensure the security of the Java platform, in addition to the Java virtual machine's own root loader (the root loader is implemented by C + +, Without the parent loader), the rest of the ClassLoader has only one parent loader. When a Java program requests load Loader1 load a class, Loader1 first delegates its own parent loader to load the class, if the parent loader also has a parent loader, and so on, and so on, if the parent loader can be added, then there is a parent loader complete loading, otherwise the loader1 itself will be loaded.

It is important to note that the parent-child relationship between the loaders here actually refers to the wrapper relationship between the loader objects, not the inheritance relationship between the classes. A pair of parent-child loaders may be 2 instances of the same loader class, or they may not be, just wrapping a parent loader object in a child loader object.

If a class loader succeeds in loading the sample class, the ClassLoader is defined as the class loader, and all class loaders (including the definition ClassLoader) that successfully return a reference to the Clas object are called the initial class loaders.

The parental delegation model is a bit of the ability to improve the security of software systems. Under this mechanism, a user-defined class loader cannot load a reliable class that should be loaded by the parent loader, thereby preventing unreliable and even malicious code from being loaded by the parent loader. For example: The Java.lang.Object class is always loaded by the root loader, and no other user-defined ClassLoader can load the class.

Run-time Package

Classes loaded by the same class of loaders that belong to the same package make up the run-time package, deciding whether the two classes belong to the same run-time package, not only to see if their package names are the same, but also to see if the class loader is the same. Only classes that belong to the same run-time package can access each other's classes and class members that are visible to the package (that is, the default access level). Such restrictions can prevent user-defined classes from impersonating the core class library's classes to access the core class library's package visible members.

Suppose the user has customized a class: Java.lang.Spy, and loaded by the user-defined ClassLoader, because the Java.lang.Spy and core class libraries java.lang.* loaded by different loaders, they belong to different run-time packages, Therefore, java.lang.Spy cannot access the visible members in the core class library Java.lang package.

Our next article focuses on how to implement a custom class loader

Deep Java Virtual machine learning-the loading mechanism of classes (iii)