Java programming extreme test: classloader class loading policy

I personally think that the ultimate test in Java programming is to master and use the classloader mechanism flexibly, especially in complex systems, such as dynamic class loading, reflect, EJB, and AOP.

Class. forname ()
And thread. currentthread (). getcontextclassloader ())
Is it the same?

In many articles, the two are considered the same. For example, an article in the Java research organization was searched by Google:
Http://www.javaresearch.org/article/showarticle.jsp? Column = 31 & Thread = 10178
This method can be replaced by class. forname (). In general, this method can be replaced, but sometimes it cannot be replaced.

Classloader has the following problems:
Multiple classloader may exist in one JVM, and each classloader has its own namespace. A classloader can have only one class Object Type instance, but different classloader may have the same class object instance, which may cause a fatal problem. For example, classloadera loads Class A's type instance A1, while classloaderb also loads Class A's object instance A2. Logically speaking, a1 = a2, but because A1 and A2 come from different classloader, they are actually completely different. If a defines a static variable C, then C has different values in different classloader.

Therefore, studying the classloader policy of JBoss is advantageous for better implementation of EJB component assembly, because EJB components of other projects may be used in one project, how to share EJB components during running is very important to package EJB components.

To demonstrate that classloader is critical to a complex architecture, list the servivesmanager class content in the open-source portal product exo.

This class is used by exo to initialize functional service JavaBeans using picocontainer. When loading those service-type JavaBeans to Pico, you need to use classloader,
Exo sets up a special servicecontext class:

Public class servicecontext {private classloader Cl; // includes classloader information private services Services; Public servicecontext (classloader Cl, Services) {This. CL = Cl; this. services = services;} public classloader getcl () {return Cl;} public services getservices () {return services ;}}

In servicesmanager, there are:
Private classloader updatedclassloader;

Its initial value is:
Thread. currentthread (). getcontextclassloader ();

If class. forname is easy to write here, you have a headache.

However, this is not enough:
In the addservice method, class loading is implemented based on different servicecontext values:

Public void addservice (servicecontext context) {services servicestoadd = context. getservices (); string name = servicestoadd. getname (); urlclassloader Cl = NULL; If (context. getcl () instanceof urlclassloader) {Cl = (urlclassloader) context. getcl ();} else {Cl = urlclassloader. newinstance (new URL [] {}, context. getcl ();} updatedclassloader = new urlclassloader (Cl. geturls (), updatedclassloader); synchronized (servicescontext) {servicescontext. put (name, context); reloadcontainer ();}}

In fact, it is very easy to add a service to picocontainer. The main code of the above method is to process classloader. Considering that classloader has a nested relationship, the above Code carefully uses the parent classloader of this service, use the parent classloader to load the service.