In "Take Control of Class Loading in Java," from DevX, author Jeff Hanson says that "By building a classloading component container framework that isolates Java class loading to a specified jar file, you can be confident that the runtime will load the component versions you expect." This can be a problem in J2EE environments, so understanding it is useful.

Java's class loading framework is powerful and flexible. It allows applications to access class libraries without linking to static "include" files. Instead, it loads archive files containing library classes and resources from designated locations, such as directories and network locations defined by the CLASSPATH environment variable. The system resolves run-time references to classes and resources dynamically, which simplifies updates and version releases. Nevertheless, each library has its own set of dependencies—and it is up to developers and deployment personnel to make sure that their applications properly reference the correct versions. Sadly, the combination of the default class-loading system and specific dependencies can and does lead to bugs, system crashes, and worse.

He follows this with a detailed discussion of creating a new URLClassloader instance that specifically looks up versions of jar files (creating a classloader much like one would find in a web app.) In a secured application server (which is the default condition only in WebSphere, of the majour application servers), creating a classloader in user code is not allowed, so the technique might not apply, but classloader understanding is of great value to Java coders regardless of the environment they use, possibly providing explanations for some odd bugs as well.

Seems a lot like OSGi.

Hi, I agree with you when you say: Java ClassLoader is a powerfull tool. I know how to customize classloader to include within classpath all classes that are zipped in a Jar o in a zip file. So you can write an application server that start using as classpath just a jar file where it's defined the customiziation of classloader and then all other components, that runs on this applications server, can put their jars files in a specified directory. Custom ClassLoader will include all jars files, located within specified directories , within Classpath and everything is Ok. But if you cannot write your application server and you are forced to develop on an existent container (e.s. JBoss) that has defined it's classloader, how can I customize classloader ? I mean, If I want to write my application and I want to use JBoss as application server, I have to put within CLASSPATH variable all classfolder location and/or all jar files that contain byte code. How can I include within JBoss classpath all my byte code without customize CLASSPATH variable ?

You can still write your own class loaders within the application code (http://www.onjava.com/pub/a/onjava/2005/01/26/classloading.html) which is supposed to be deployed in JBoss - But the problem is, J2EE literatures forbid custom handling of class loaders inside app servers. So poor developer is in between "Do" and "Don't-Do" situation !!

The sooner JSR277 arrives and eliminates the need for these kinds of shenanigans, the better...

The problem is that it cannot cast the object loaded with a component without having the interface for it in the main package. And if the interface changes you have to reload the whole app.

I'm not sure about the real value of this framework when it comes to J2EE. I would rather trust the J2EE platform implementation to handle class-loading and not introduce thin in J2EE env . Besides I'm not sure how often this versioning problem exists in real-life. For instance J2EE implementation may choose (if most doesn't already do) to load each DB-driver when defining the datasources by distinguished class-loaders. The article speeks about "hot-deployment" but then again it relies on URLClassLoader which uses JarURLConnection to handle .jar files and deeper then that details are handeled natively. Which is fine but when you need to unload classes (for true undeploy behavior) even if URLClassLoader is eligible for GC, the resources (.jar files) are not really released and they may naver be (see finalize from ZipFile class which calls close() which of course URLClassLoader doesn't provide any abstraction of closing acquired resources). So how valuable hot-deployment really is without true undeployment?