[jsr294-modularity-eg] Superpackage defining class loader
glyn_normington at uk.ibm.com
Wed Apr 25 05:17:40 EDT 2007
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
* 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
Essentially, I'm saying that if we deleted nested superpackages, we could
delegate the responsibility to support large projects to the deployment
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
> We can leave this as an open issue and revisit it in case someone comes
> with a use case.
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jsr294-modularity-eg