Good, then
The general application has 3 standard classloaders:
- Class Loader
- Classloader Extenders
- Class-Classpath System Loader
So far so good. Now it works for one application, working alone and for free.
But what happens when you say J2EE? You have several applications running in the same place, so you need to figure out a way to prevent them from stumbling with each other. That these additional class loaders come into play.
Think of a server instance. There is a JBoss with two deployed EARs. What happens if there are conflicting classes between applications? They are fine in their particular context, but overall they are inconsistent.
These additional class loaders are introduced differently to provide isolation between them. The class loaders below the Class-Classpath Classloader recognize a class only if it is specified in the manifest file for one of its children.
In J2SE, the three main class loaders work in a parent-child relationship based on three principles:
- Delegation: if the class is not loaded (cache), the request is delegated to its parent element. This continues to the top of the hierarchy (Bootstrap class loader), which loads the base classes associated with J2SE (e.g.
Integer , ArrayList , among others). This is what you refer to in your question: The class loader delegates the load to the top of the hierarchy, then each class loader tries to load the class if its parent could not find it until someone loads it. Otherwise: ClassNotFound. - Visibility: classes loaded by the parent class loader are visible to its children, and not vice versa.
- Uniqueness: if the parent class loader loads the class, children never reload it.
In Java SE, the class loader delegates class loading to the parent class loader, and then tries to load the class itself.
True, due to the principles described above.
J2EE does not have a specific classloader structure (the provider has a “poetic license” to implement it), but they see a hierarchy. In this case, the System-classpath class loader loads the main application: the server. Then the server libraries (its classes, more specifically) are accessible to each application due to the principle of visibility.
At the bottom of the application, there are certain class loader structures, but in general they are different children of the System-classpath class loader. Each application loads related and specific classes (both applications and libraries).
The download here does not apply to parents outside the context of the application. What for? because if the class loader System-classpath was supposed to load applications, as usual, the class of each application will be visible to others due to the principle of visibility, completely breaking isolation between themselves. So:
However, in Java EE, the class loader first tries to load the class itself, and then delegates the class loading of this class to its parent class loader.
This is partly true, but I would prefer to limit this assertion to the application context and not take into account Java classes that are really loaded by top-level class loaders.
In short: this is not an easy process, but I would not say that J2EE handles class loading differently around J2SE.