[jsr294-modularity-eg] Nested superpackages

[Bryan Atsatt]

Agreed on both counts. Although developers are used to the restriction that only one instance of a given class name can be defined in a given loader, the nested superpackage suggests another namespace, which would lead to the assumption that this restriction doesn't apply.
 
I don't like the bi-directional declarations here, as it will be a maintenance issue. My sense is that nested superpackages wouldn't be used much in practice: it's a level of control that I suspect most developers wouldn't feel strongly about, and the overhead of declaring them will be enough of a barrier to prevent their use. Sure, there will be some who would like it, but I don't think the benefit outweighs the added complexity...
 
// 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: Monday, April 23, 2007 6:19 AM
	To: JSR 294 Expert Group
	Subject: Re: [jsr294-modularity-eg] Nested superpackages
	
	

	"Bryan Atsatt" <bryan.atsatt at oracle.com> wrote on 20/04/2007 18:23:17:
	
	> Yes, but that is certainly a much simpler model. Do you think this 
	> is a significant restriction? 
	
	Yes - conceptually it's yukky. I know people could work around it and tooling could help, but it seems analogous to not being able to declare a local variable because it is already declared in an enclosing scope. I would rather scrap nested superpackages. 
	
	They also seem pretty limited because, as currently defined, a nested superpackage is tightly bound to its parent (it names its parent). So they don't provide a naming scope or a unit of reuse. 
	
	>   
	> // 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: Friday, April 20, 2007 6:22 AM
	> To: JSR 294 Expert Group
	> Subject: [jsr294-modularity-eg] Nested superpackages
	
	> 
	> Must a nested superpackage be defined by the same class loaders as 
	> its parent (enclosing) superpackage? 
	> 
	> If so, this would seem to put a restriction on the class names in a 
	> nest of superpackages: there must be no duplicates. This is a little
	> surprising as it means unexported internals of a (nested) 
	> superpackage can cause problems depending on the content of the 
	> parent superpackage. 
	> 
	> Glyn _______________________________________________
	> jsr294-modularity-eg mailing list
	> jsr294-modularity-eg at cs.oswego.edu
	> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
	
	Glyn 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070423/a666519b/attachment.html