[jsr294-modularity-eg] Superpackage defining class loader

[Glyn Normington]

I've yet to see a convincing use case for nested superpackages and I don't 
think we should keep the feature without gaining concensus on the need for 
it, but assuming nested superpackages turn out to be necessary, would it 
be possible to make the type names inside nested superpackages unique by 
adding some kind of prefix similarly to the way nested classes are named? 
I think this would prevent the 'leakage' of unexported information.

Glyn

Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 26/04/2007 08:42:05:

> 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.
> 
> _______________________________________________
> 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/20070426/dc9aa6b7/attachment.html