[jsr294-modularity-eg] Superpackage defining class loader

[Andreas Sterbenz]

Glyn Normington wrote:
> 
> 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.

Note that at the language level you cannot have multiple types of the same 
name today. Adding superpackages to the language does not change that. See 
my message Re: Nested superpackages from 4/23 
(http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2007-April/000034.html)

> * 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.

That is correct.

> 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. 

I agree. In your example B and C appear to be loosely coupled so it makes 
sense to have them as separate top-level superpackages (and deployment 
modules) regardless of all other issues.

That is a fine answer. It also addresses the issue we were discussing in 
this thread: is there a use cases where it is necessary to load a spkg 
file and its class files using different class loaders? This example is no 
such use case, so we should stick with current proposal that a 
superpackage should be defined by a single classloader.

> Are there any specific examples where it would make more sense to use 
> nested superpackages than separate deployment modules?

Nested superpackages are not a replacement for deployment modules, they 
solve a different issue. I can certainly show an example from the code I 
am most familiar with (part of the core of the JDK) to make the 
explanation from the mail I sent yesterday more concrete. The issue 
remains the same:

Without nested superpackages we cannot achieve the same level of 
information hiding. Given that information hiding is the problem this JSR 
was created to address, this is not an something we can just set aside.

Andreas.