关于java class load 的一篇经典文章

Java Class Loading

　　Raymond Lin

　　The class loading is an essential topic of Java programming language. It is the key to design and understand good Java applications. For example, Singleton pattern may not guarantee the single instance in a JVM. A surprise?

　　The class loading is also the key to understand the packaging of EJB applications and the run-time behavior of packaged EJB applications deployed on application servers, as well as the different packaging requirements on different application servers. Let's compare WebLogic v7.0 and WebSphere v5.0.

　　In WebLogic v7.0, every EJB application receives its own classloader hierarchy; the parent of this hierarchy is the system classloader. The hierarchy is automatically created when an application is deployed. The application classloader in the hierarchy loads any EJB JAR files in the application. A child classloader is created for each Web application WAR file. Note that this child Web application classloader contains all classes for the Web application except for the servlet implementation classes and JSPs. Each servlet implementation class and JSP class obtains its own classloader, which is a child of the Web application classloader. This allows servlets and JSPs to be individually reloaded.

　　The classloading design in WebLogic v7.0 isolates applications so that application A cannot see the classes of application B. Application classloaders can only see their parent classloader, the system classloader. This allows WebLogic Server to host multiple isolated applications within the same JVM.

　　In WebLogic, there is a PreferWebInfClasses setting which subverts the standard Java classloader delegation model when it is set to true. In my opinion, this is a poor design because the same class can be loaded into both the Web application and system classloader, which in turn makes it very easy to obtain a ClassCastException. Users must be very careful not to mix instances of classes loaded from different classloaders.

　　The class loading in WebSphere v5.0 is more sophisticated than in WebLogic v7.0. The overall classloader hierarchy is similar to WebLogic except that there is a WebSphere-specific extensions classloader sits in between the system classloader and application classloader. This WebSphere extensions classloader loads the WebSphere run time and J2EE classes that are required at run time from "ws.ext.dirs".

　　Unlike WebLogic which does not provide much flexibility of EJB packaging due to its classloading design, WebSphere uses Classloader Isolation Policies to specify the number and function of the application classloaders, therefore to control the isolation of applications and modules. This enables different application packaging schemes to run on an application server. There are two classloader policies.

　　The Application Classloader Policy specifies how an application classloader can be shared by multiple applications. When set to SINGLE, applications are not isolated. When set to MULTIPLE, applications are isolated from each other because each of them has its own application classloader.

　　The WAR Classloader Policy controls the isolation of Web modules. If this policy is set to APPLICATION, then the Web module contents also are loaded by the application classloader. If the policy is set to MODULE, then each web module receives its own classloader whose parent is the application classloader.

　　As a result of the classloading design, WebSphere can offer more flexible EJB packaging options, and better run-time configuration. For example, in WebLogic, you are forced to edit its script that runs WebLogic Server when you just want to share utility classes among your EJB applications.

　　The class loading is one of the most important topics in Java Security course offered at New Concept.