[jsr294-modularity-eg] Nested superpackages

[Bryan Atsatt]

Glyn Normington wrote:
> 
> *Andreas Sterbenz <Andreas.Sterbenz at sun.com>* wrote on 31/05/2007 00:57:57:
> 
>  > At JavaOne Glyn and I talked a bit about a few topics, including nested
>  > superpackages. I will try to summarize the conclusions. Glyn, please
>  > correct me if something does not match your recollection.
> 
> Thanks for accurately summarising our discussion for the list.
> 
>  >
>  > Summary: nested superpackages have value, but there is no agreement yet
>  > whether they have enough value to justify their inclusion. We need to
>  > better understand them (and explain them) before making a final decision
>  > about nested superpackages in JSR 294. One way to understand them better
>  > is to try them out in practice. As the extra complexity of implementing
>  > nested superpackages is low, the javac team has agreed to implement them
>  > as part of their JSR 294 work. The initial version of that 
> implementation
>  > is expected to be available sometime this summer.
>  >
>  > I suggest we go ahead with the plan of leaving them in for now and
>  > reexamining the solution in a few months. Please let me know if anyone
>  > disagrees.
> 
> I agree. Let's look to the broader community to provide feedback on 
> whether nested superpackages deliver sufficient value to warrant their 
> inclusion. I'd like to see one or more real life applications (rather 
> than JRE internals) that would benefit from nested superpackages and, 
> ideally, would be willing to do some prototyping and provide early 
> feedback.

+1

[snip]


The biggest issue I have with nested superpackages is the circular 
declarations. While I understand the point of this tight coupling, my 
"maintenance alert" flags are waving like mad.

If we could eliminate the circularity, the complexity factor would be 
greatly reduced, at least for me. Perhaps we could change the nested 
declaration from:

     superpackage example.bar.lib.net member example.bar.lib

to

     member superpackage example.bar.lib.net

or

     private superpackage example.bar.lib.net

Yes, this appears to open the possibility that an unexpected/undesired 
top-level superpackage could gain access. But we could simply disallow 
more than one consumer of member/private superpackages. It isn't 
perfect, but perhaps it is good enough?


The other issue is that it complicates 277, which requires additional 
metadata to piggyback on the .spkg file. If we allow more than one such 
file in a module, 277 must define precedence rules for the metadata 
consumption.

// Bryan