[jsr294-modularity-eg] Superpackage defining class loader

[Glyn Normington]

Ok, let's consider the following use case.

VERSION MISMATCH USE CASE

A large development team constructs a superpackage A containing two nested 
superpackages B and C. B and C are developed by distinct subteams. Suppose 
the developers of B have included an unexported general utility class 
org.apache.foo.Util early on in the project. Later, the developers of C 
also realise independently that they can save time by reusing 
org.apache.foo.Util, but they pick up a later version and include it as an 
unexported class of C.

Some time later, the team constructs A for the first time. It wasn't 
possible to do this earlier since B and C took quite a while to bring up 
to a basic level of function suitable for integration into A. The build 
runs successfully, but class loading errors occur since 
org.apache.foo.Util is duplicated between B and C.

The subteams then realise that they have both picked up the Util class so 
they try moving the class around and changing its visibility. They find a 
way of sharing the class (*) but then have to agree which version to use. 
It turns out extensive use has been made of the class in both B and C and 
so there is a significant delay while B is reworked to use the later 
version.

DISCUSSION

* the strawman gives the impression that B and C can see the classes 
directly contained in A and that B and C can see each other's exported 
contents. Please correct me if I've misunderstood.

It would seem much cleaner to develop B and C as top-level superpackages 
each wrapped in their own deployment module. This would avoid internals 
clashing, as B and C would be loaded by distinct class loaders. I can't 
think of a practical example where bundling B and C together in A to 
produce a large, monolithic superpackage would make a lot of sense, and 
I've worked on a lot of large projects. Are there any specific examples 
where it would make more sense to use nested superpackages than separate 
deployment modules?

Essentially, I'm saying that if we deleted nested superpackages, we could 
delegate the responsibility to support large projects to the deployment 
module.

Glyn

Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 25/04/2007 07:20:08:

> Glyn Normington wrote:
> > 
> > I don't have a specific use case where this would be a problem except 
> > the general use case of someone trying to understand the 294 
> > specification and how it relates to class loaders.
> 
> If there is no use case, we should go with the simple solution for now, 
> i.e. a superpackage and its classes are defined by the same class 
loader. 
> We can leave this as an open issue and revisit it in case someone comes 
up 
> with a use case.
> 
> Andreas.
> 
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU





-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070425/88cae370/attachment.html