Figure 1 parent delegation model
It should be pointed out that Class Loader is an object, and its parent-son relationship has no relationship with the parent-son relationship of the class. A parent-child loader may be instantiated from the same Class, or it may not be, and even the parent loader is instantiated from the subclass and the child loader is instantiated from the parent class. Assuming that MyClassLoader inherits from ParentClassLoader, we can have the following parent-child loader:
ClassLoader loader1 = new MyClassLoader();
//The parameter loader1 is parent
ClassLoader loader2 = new ParentClassLoader(loader1);
So why is the parent delegation model safer? Because under this model, a user-defined class loader cannot load a reliable class that should be loaded by the father loader, preventing unreliable or even malicious code from replacing the reliable code loaded by the father loader. In fact, the writer of the class loader has the freedom to choose not to delegate the request to parent, but as mentioned above, it will cause security problems.
Namespace and its functions
Each class loader has its own namespace, and the namespace consists of all classes that use this loader as the initial class loader. Two classes in different namespaces are invisible, but as long as you get the reference of the Class object corresponding to the class, you can still access the class in another namespace.
Example 2 demonstrates how a class in a namespace uses a class in another namespace. In the example, LoaderSample2 is loaded by the system class loader, and LoaderSample3 is loaded by a custom loader loader. The two classes are not in the same namespace, but LoaderSample2 gets the reference of the Class object corresponding to LoaderSample3, so it can access public members (such as age) in LoaderSampl3.
Example 2 Access to classes in different namespaces
/**/import .*;import .*;public class LoaderSample2 { public static void main(String[] args) { try { String path = (""); URL[] us = {new URL("file://" + path + "/sub/")}; ClassLoader loader = new URLClassLoader(us); Class c = ("LoaderSample3"); Object o = (); Field f = ("age"); int age = (o); ("age is " + age); } catch (Exception e) { (); } }
}
/*sub/*/public class LoaderSample3 { static { ("LoaderSample3 loaded"); } public int age = 30;}
Compilation:
javac ;
javac sub/
Run: java LoaderSample2
LoaderSample3 loaded
age is 30
As can be seen from the run result, in class LoaderSample2, you can create an object in class LoaderSample3 in another namespace and access its public member age.
Runtime package (runtime package)
The class belonging to the same package defined by the same class loader constitutes the runtime package. Deciding whether the two classes belong to the same runtime package, it not only depends on whether their package names are the same, but also whether the class loader is the same. Only classes belonging to the same runtime package can access each other's visible classes and members. Such restrictions avoid the situation where users' own code impersonates the core class library class to access visible members of the core class library package. Suppose the user defines a class himself and loads it with a user-defined class loader. Since it is loaded by different loaders, they belong to different runtime packages, so they cannot access visible members of the packages of the class in the core class library.
Summarize
After briefly discussing class loaders, parent delegation models, namespaces, and runtime packages, I believe everyone has a certain understanding of their role. Namespaces do not completely prohibit mutual access of classes belonging to different spaces. The parent delegate model strengthens Java security, and the runtime package increases protection for visible members of the package.