commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: AW: AW: [proposal] avoiding jar version nightmares
Date Sun, 19 Dec 2004 21:46:24 GMT
On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
<> wrote:
> This may work, but does BCEL require the use of its own custom
> classloader also?
> This seems to me that this isn't just a problem with commons; it is a
> problem with Java itself that .NET already has a very nice solution for.
>   I'm wondering if this isn't something that should be taken care of at
> the JVM level i.e. - in Java 1.6.  The obvious solution seems to be that
> we need to fix classloaders.  They're already a huge nightmare in EJB
> containers.
> How do we go about petitioning Sun for something like this?

A while back now (while the details for Tiger were being planned), I
happened to be in a meeting with Graham Hamilton (who basically owns
the direction that J2SE is going from a Sun perspective), talking
about the very issue of class loaders and the contortions that you
have to go through in order to implement things like webapp reloading.
 I asked him for a Christmas present to all Java developers -- add
something like ClassLoader.unloadClass() or ClassLoader.replaceClass()
to deal with things like this.  He said "hmm ... that's a hard
problem" and proceeded to describe several of the places where
implementing this would be extremely difficult (and/or would have
nasty performance impacts) in the current architecture of JVMs.

Regarding the original use case in this thread (an app that wants to
use two modules that have conflicting versions of common
dependencies), about the best you can do right now is to have your
application create its own class loaders for the modules involved, and
set up their classpaths to pick up their own versions of the
dependencies.  That is essentially what a servlet container does
(creates a class loader for each webapp) to maintain separation, and
allows each webapp to load its own version of a common dependency JAR
from its own "class path" ... the /WEB-INF/classes and /WEB-INF/lib
directories of that app.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message