Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of craigmcc@gmail.com designates
 64.233.170.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=GTSXTYVdFpQTfjcdtVspAi3AKYipavyr1ztpxZyT/EAR/INfjdQkaFx4kghFEeGW49WJPVe1cqyFyYSXBiQW+RfKN/8uQ0rCTY1zcKkEZXSAXSs/hOB4X13xJ277I6kuZdYS5GY4B2nJjAhtzL8eyJIETcrBdDEAB/2dFwzaJJU=
Message-ID: <f8b39ace0412191346db05122@mail.gmail.com>
Date: Sun, 19 Dec 2004 13:46:24 -0800
From: Craig McClanahan <craigmcc@gmail.com>
Reply-To: craigmcc@apache.org
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: AW: AW: [proposal] avoiding jar version nightmares
In-Reply-To: <cpvshp$htp$1@sea.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <9da4f45204121613441341cfaa@mail.gmail.com>
	 <E1CfPSz-0003dG-00@smtp07.web.de>
	 <9da4f45204121715154ead669f@mail.gmail.com>
	 <cpvshp$htp$1@sea.gmane.org>

On Fri, 17 Dec 2004 19:10:32 -0500, Matt Sgarlata
<sgarlatm@users.sourceforge.net> 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.

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org