[jsr294-modularity-eg] Nested superpackages

[Glyn Normington]

Yes, I can see the theoretical justification for a nested superpackage 
construct. I'm just struggling to understand its practical usefulness in 
large projects given that deployment modules give a clean way of dividing 
up a large project which prevents unexpected version clashes. I'd be 
interested in feedback from the community observing this list.

Glyn

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

> Glyn Normington wrote:
> > 
> > What do we really lose by deleting nested superpackages? In these 
> > situations, my feeling is that "less is more" and deleting this 
feature 
> > will strengthen the whole proposal.
> 
> Not having nested superpackages would mean instead of a project having a 

> top level superpackage and a nested superpackage for each subsystem, all 

> classes of the project would be a member of the top level superpackage. 
It 
> could hide implementation details from code outside the superpackage by 
> declaring such public classes as non-exported, but it would not be 
> possible to isolate subsystems within the project from each other.
> 
> In particular, a class that is used by multiple packages of a subsystem 
> would have to be a (non-exported) public class even if it is an 
> implementation detail of the subsystem. That means it could accidentally 

> be used by other subsystems within the project.
> 
> In other words, we have the same problem we have today with package 
based 
> access control: it is not possible to hide implementation details as 
> desired. Just as we currently have that issue for projects too large to 
be 
> appropriate for a single package, we would have the same issue for 
> projects that are too large to be appropriate for a single superpackage.
> 
> That means we would be addressing only part of the problem JSR 294 set 
out 
> to solve. That is not the correct goal for us.
> 
> We should keep in mind that the added conceptual weight of nested 
> superpackages is very low. They are not a concept distinct from 
> superpackages, just a recursive application of the same idea. Nor do 
they 
> complicate live for developers who prefer to stay with a flat system and 

> not to use nesting.
> 
> 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/0bdd0b74/attachment.html