The ClassLoader and package mechanism of Java

To get a closer look at the classloader mechanism of Java, let's start with the following experiments:

Package Java.lang;
public class Test {
public static void Main (string[] args) {
Char[] C = "1234567890". ToCharArray ();
string s = new string (0, C);
}
}

The string class has a constructor string (int offset, int length, char[] array) with a package permission, and the default access permissions, Because test belongs to the Java.lang package, you should theoretically be able to access this constructor of string. Compile through! The results of the implementation are as follows:

Exception in thread "main" java.lang.SecurityException:Prohibited Package name:
Java.lang
At Java.lang.ClassLoader.defineClass (Unknown Source)
At Java.security.SecureClassLoader.defineClass (Unknown Source)
At Java.net.URLClassLoader.defineClass (Unknown Source)
At java.net.urlclassloader.access$100 (Unknown Source)
At Java.net.urlclassloader$1.run (Unknown Source)
At Java.security.AccessController.doPrivileged (Native method)
At Java.net.URLClassLoader.findClass (Unknown Source)
At Java.lang.ClassLoader.loadClass (Unknown Source)
At Sun.misc.launcher$appclassloader.loadclass (Unknown Source)
At Java.lang.ClassLoader.loadClass (Unknown Source)
At Java.lang.ClassLoader.loadClassInternal (Unknown Source)

Weird, huh? To figure out why there is a SecurityException, you have to figure out the ClassLoader mechanism.

Java ClassLoader is used to dynamically load class, ClassLoader to a class will only be loaded once, the JVM uses a total of 4 kinds of ClassLoader:

Start class loader, Standard extended class loader, Classpath loader and network class loader.

These 4 types of ClassLoader are prioritized from highest to lowest, using the so-called "parental delegation model". Exactly speaking, If a network class loader is requested to load a java.lang.Integer, it will first send the request to the class path loader at the top level, and if the return is mounted, the network class loader will not load the Java.lang.Integer, and it will not load the JA if the classpath loader at the upper level returns to an unmounted Va.lang.Integer.

Similarly, when a classpath loader receives a request (whether it is a request for a direct request or a ClassLoader upload at the next level), it also sends the request to the standard extended class loader at the top level, so that a layer of upload is made so that the boot class loader has the highest priority, If it finds java.lang.Integer in its own way, the following classloader can no longer load java.lang.Integer, even though you have written a java.lang.Integer yourself, attempting to replace the core library of Java.lang.Intege R is impossible, because this class that you write cannot be loaded by the classloader of the lower layer at all.

Again, package permission. The Java language stipulates that class in the same package, if there are no modifiers, default to package permissions, and the class within the package can be accessed. But that's not accurate enough. Specifically, only the class loaded by the same ClassLoader has the package permission. For example, the boot class loader loads the java.lang.String, the classpath loader loads the java.lang.Test we write ourselves, and they cannot access each other's methods with package permissions. This prevents malicious code from accessing the package permission method of the core class.