Ben Galbraith's Blog

Community: Java Enterprise Archives

Classloading in J2EE Applications

I've spent the last two or three years doing a large amount of client-side Java development. In that world, there are a number of techniques for partitioning the various JARs that compose the application into distinct class loader domains.

For example, using the Eclipse RCP, you can define your application as a set of plug-ins and define exactly which JARs *other* plug-ins can see.

Consider the following scenario: I have two frameworks, Foo and Bar. Framework Foo depends on a library called Commons-Sniping 1.0, and Framework Bar depends on a different version of the same library (Commons-Sniping 3.2). Version 3.2 breaks a bunch of 1.0 APIs and introduces its own new stuff.

Having Foo, Bar, and both versions of Commons-Sniping exist in the same class loader domain is foolish with a capital F. Weird, exotic, and fun errors can and will occur at run-time. So, you make Foo and Bar plug-ins, and define that those plug-ins only expose the Foo and Bar API. As a result, only Foo can see Commons-Sniping 1.0, and only Bar can see Commons-Sniping 3.2. And, things are good.

So, the other day I had this problem in the context of a web application. Two frameworks relied on different versions of the same library, and versions were different by a major version (e.g., 2.x and 3.x). So, uh, what do I do?

I asked several J2EE developer friends whom I respect. And the answers I got from all were, "Uh, choose the latest version and hope for the best." Hmm...

Is this really the state-of-the-art for J2EE development? Do some app servers provide class loader partitioning services to web applications? Or do I have to do my own integration with one of the third-party plug-in engines out there? Or, do you just rely on libraries to not ever be backwards incompatible? How do you solve this problem?

This work is licensed under a Creative Commons License.