[jsr294-modularity-eg] Nested superpackages

[Bryan Atsatt]

I had the same reaction initially (use modularity for such isolation rather than nested superpackages), but there may be use cases where switching to a modularity solution isn't feasible/practical/desirable. I don't actually know of any myself, however...
 
// Bryan
 
________________________________

From: jsr294-modularity-eg-bounces at cs.oswego.edu [mailto:jsr294-modularity-eg-bounces at cs.oswego.edu] On Behalf Of Glyn Normington
Sent: Wednesday, April 25, 2007 2:23 AM
To: JSR 294 Expert Group
Subject: Re: [jsr294-modularity-eg] Nested superpackages




	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/3307e6b4/attachment.html