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.
-
Take Control of Class Loading in Java (6 messages)
- Posted by: Joseph Ottinger
- Posted on: June 02 2006 08:12 EDT
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.Threaded Messages (6)
- Re: Take Control of Class Loading in Java by Frank Bolander on June 02 2006 10:44 EDT
- How to define Class Loader within Application Server by Renato Del Gaudio on June 05 2006 17:33 EDT
- Re: How to define Class Loader within Application Server by binildas christudas on June 06 2006 01:07 EDT
- How to define Class Loader within Application Server by Renato Del Gaudio on June 05 2006 17:33 EDT
- Re: Take Control of Class Loading in Java by Peter Monks on June 02 2006 11:40 EDT
- Re: Take Control of Class Loading in Java by urddd urddd on June 02 2006 12:00 EDT
- The value ... by Marius Danciu on June 04 2006 15:12 EDT
-
Re: Take Control of Class Loading in Java[ Go to top ]
- Posted by: Frank Bolander
- Posted on: June 02 2006 10:44 EDT
- in response to Joseph Ottinger
Seems a lot like OSGi. -
How to define Class Loader within Application Server[ Go to top ]
- Posted by: Renato Del Gaudio
- Posted on: June 05 2006 17:33 EDT
- in response to Frank Bolander
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 ? -
Re: How to define Class Loader within Application Server[ Go to top ]
- Posted by: binildas christudas
- Posted on: June 06 2006 01:07 EDT
- in response to Renato Del Gaudio
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 !! -
Re: Take Control of Class Loading in Java[ Go to top ]
- Posted by: Peter Monks
- Posted on: June 02 2006 11:40 EDT
- in response to Joseph Ottinger
The sooner JSR277 arrives and eliminates the need for these kinds of shenanigans, the better... -
Re: Take Control of Class Loading in Java[ Go to top ]
- Posted by: urddd urddd
- Posted on: June 02 2006 12:00 EDT
- in response to Joseph Ottinger
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. -
The value ...[ Go to top ]
- Posted by: Marius Danciu
- Posted on: June 04 2006 15:12 EDT
- in response to Joseph Ottinger
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?