users@javaee-spec.java.net

[javaee-spec users] Re: [jsr342-experts] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

From: Craig Ringer <ringerc_at_ringerc.id.au>
Date: Fri, 27 Jul 2012 08:03:16 +0800

On 07/26/2012 11:30 PM, Jason T. Greene wrote:
> Really? You have never seen users complain about EE classloader
> isolation problems? It's pretty common these days for EE deployments
> to suck in 10+ libraries that conflict with another deployments 10+
> libraries.

Two different things are being conflated by this discussion.

(a) A user-exposed module system where applications can express
dependencies on modules provided by the container or other applications; and

(b) Improvements to classloader isolation and internal modularity within
app servers, allowing them to solve library and class version conflicts
between deployments and between the app server and a deployment
/without/ having to expose the guts of the module system to users.

It is important to distinguish between these two things. (b) is a means
to solving problems; (a) is an end in its self.

I've had enough problems with conflicts - and see enough on Stack
Overflow etc - to believe that (b) will make the platform much more
usable for beginning and new developers, and reduce the frustration of
working with the platform. However, it's already achieved without
explicit support from the spec.

I can easily believe that (a) might be very important, but it is
/already catered for by OSGi/ for those who need it. OSGi isn't great,
but can this group come up with a better solution than OSGi - in the
time available, or at all? If so, start getting an EG together for a
JSR, because you're going to need to work on a dedicated spec for it.

--
Craig Ringer