Today's hero is "parent delegation model", referred to as "dual-mode."
That "dual-mode" Who is?
Text from the surface meaning to understand, this "dual-mode" is a template, or similar to a regular system.
So why is it called "parent delegation model" mean? In fact, I do not know.
English name from the point of view (parent-delegation model), the parent may be the direct translation in English is "both parents" means right, and therefore called the "parent delegation model" is purely guessing, no literature to guide! ^ _ ^ ~~
To be specific, "dual-mode" is a fixed hierarchical relationship between the class loader . Relationship as shown below:
So the question becomes, what class loader is?
What is the class loader
Virtual machine design team in the class loading phase "to get through the fully qualified name of a class description of such a binary byte stream" this action to the outside Java virtual machine to achieve,
to allow the application to decide how to get the the necessary classes. This action is achieved code module called a "class loader."
So what is it like to load? This problem will not go into details here, write a book, ha ha ha.
Class and class loader:
"For any class, it needs to establish a loaded class loader and the class itself with its uniqueness in the Java virtual machine, each class loader has a separate class name space."
Determining a class which must be unique on the java virtual machine is loaded by the class loader and its original class together.
Conversely, due to the class itself is fixed, that is a Class from the same file, that determine the uniqueness of this class is the class loader loads the class to determine the different classes loaded out of the class the examples are not identical.
"Dual-mode" Where did it come from?
"Parents delegation model" of course, is designed Java designers out of it.
Principle model parents delegate
In addition to the parent delegation model requires top-level boot loader class, the rest of the class loader should have its own parent class loader.
Parent-child relationship between the class loader herein generally will not inherit (Inheritance) relationship is achieved, but use a combination of (Composition) multiplexed code in relation to the parent loader.
Parent delegation model of working process is:
if a class loader loads the class received a request, it first does not own to try to load this class, but to delegate this request to the parent class loader to complete each level of the class loader is the case,
when the load so that all requests should be transferred eventually to the top of the boot class loader, loader feedback only when the parent they can not complete the loading request (its search did not find the desired category) , child loader will try to load your own.
Classification class loader
"From the perspective of the Java virtual machine is concerned, there are only two different class loaders: one is to start class loader (Bootstrap ClassLoader), the class loader uses the C ++ language, is part of the virtual machine itself;
another is that all kinds of other class loader, the class loader by Java language, independent of external virtual machine, and all derived from the abstract class java.lang.ClassLoader. "
From the point of view of the virtual machine, class loader only two kinds:
1 species is to start class loader (Bootstrap ClassLoader), the class loader uses the C ++ implementation, is part of the virtual machine itself.
The second is another class loader , the class loader is implemented by the Java language, independent of external virtual machine, and all derived from the abstract class java.lang.ClassLoader.
From the point of view Java developers, there are class loader class loader 3 or less (1) provided by such systems.
First type is a boot class loader (Bootstrap ClassLoader)
Responsible will be stored in the <JAVA_HOME> \ lib directory, or by -Xbootclasspath parameters specified path, and a virtual machine identification (only by file name recognition, such as rt.jar, even if the name does not meet the library the lib directory will not be loaded) libraries loaded into the virtual machine's memory.
Start class loader can not be directly referenced Java program, users write custom class loader, if you need to load the delegates to the bootstrap class loader that can be used directly instead of null.
No. 2 is extended class loader (Extension ClassLoader):
This loader is implemented by sun.misc.Launcher $ ExtClassLoader, it is responsible for loading <JAVA_HOME> \ lib \ ext directory, or by all libraries, developers java.ext.dirs system variables specified path can be directly using the extended class loader.
A third is the application class loader (Application ClassLoader):
This class loader is implemented by sun.misc.Launcher $ App-ClassLoader. Since the class loader is the ClassLoader getSystemClassLoader () Returns the value of the method, it is generally called the system class loader.
It is responsible for loading the user class path (ClassPath) designated libraries, developers can directly use this class loader, if the application is not too own custom class loader, in general, this program is the default category Loader.
Fourth custom class loader: if necessary.
"Dual-mode" where you want to go?
Meaning parents delegate model?
"Using the model of the relationship between the parents appointed to organize the class loader, there is an obvious advantage is that Java class with its class loader has the priority level together with a relationship of.
" Parent delegation model to organize the relationship between class loader, one kind of forming a stable relationship with the priority level, the uniqueness of a class is loaded out, maintenance of the system.
It can be summarized as follows: In order to maintain peace and stability in the Java programming system development.
"Dual-mode" but also frustration
One frustration: "the father of the child subordinated debt."
Because parents delegation model was only introduced after JDK 1.2, and class loader and abstract classes java.lang.ClassLoader have existed in the early JDK 1.0 era, the face of the user from existing code that implements custom class loader,
the Java designers introduced parents had to make some compromises when you delegate model. For backward compatibility, JDK java.lang.ClassLoader after 1.2 adds a new protected method findClass (),
before that, to inherit the user's sole purpose is to rewrite java.lang.ClassLoader loadClass () method, because when the virtual machine during the class loader will call the loader private methods loadClassInternal (),
and the only logic of this method is to call your own loadClass ().
JDK 1.2 After covering the deprecated user go loadClass () method, but should put its own class loader logic writes the findClass () method,
In the logic loadClass () method in the parent class loader if that fails, it calls its own findClass () method to finish loading, so that you can ensure that the new written class loader is in line with parents delegate rules.
Helpless two: insufficient born helpless.
From this model's own defects caused parents appoint a good solution to the problem of unified class basis of each class loader (the base of the upper class by the loader to load), the base class is called "foundation ",
because they are always invoked as an API user code, but things are often not absolutely perfect, if the base class have to call back to the user code, then how to do?
To solve this problem, Java design team had introduced a less elegant design: the thread context class loader (Thread Context ClassLoader).
This class loader can be set by setContextClassLoaser () method java.lang.Thread class, if not set when a thread is created, it will inherit from a parent thread,
if not set globally through the application , then the class loader is the default application class loader.
With the "thread context class loader", the equivalent of holding a plug-in, you can do some "fraud" thing.
Service JNDI using the thread context SPI class loader to load the desired code, which is the parent class loader sub-class loader request to complete the loading of Action,
This behavior is actually open up the hierarchy of parent delegation model to reverse the use of the class loader has actually violated the general principles parent delegation model,
But no one could do. All Java loading operation involves basically the SPI this way, e.g. JNDI, JDBC, JCE, JAXB JBI, and the like.
Helpless three: the world where the only constant is always changing.
Because users pursuit of dynamic program which led to, here called "dynamic" refers to the current some very "hot" terms: the code hot-swap (HotSwap), module hot deployment (Hot Deployment), etc.,
that white it is hoped that the application can, as we connect computer peripherals mouse, U disk, can be used immediately without restarting the machine, the mouse have questions or want to upgrade to another mouse, you do not stop do not have to restart.
For the personal computer, the reboot is actually no big deal, but for some production systems, shutdown, reboot may have to be classified as industrial accidents, in which case it is hot deployment of software developers,
particularly in business class software developers have great appeal.
In the OSGi environment, parent class loader is no longer delegated tree model, but further development of a more complex network structure,
When receiving a load request class, OSGi-based search will be in the following order:
1) will java. * Class assigned to the beginning of the parent class loader loads.
2) Otherwise, the delegate class delegate to the parent class loader loads the list within a list.
3) Otherwise, the Import list of classes assigned to this class Bundle of Export class loader.
4) Otherwise, find the current Bundle of ClassPath, uses its own class loader.
5) Otherwise, look for classes in their own Fragment Bundle whether, if in, then delegated to Fragment Bundle class loader loads.
6) Otherwise, find Bundle Dynamic Import list, assigned to the corresponding Bundle class loader to load.
7) Otherwise, the class lookup fails.