[jsr294-modularity-eg] Nested superpackages
bryan.atsatt at oracle.com
Thu May 31 14:42:09 EDT 2007
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
> > 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
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
superpackage example.bar.lib.net member example.bar.lib
member superpackage example.bar.lib.net
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
More information about the jsr294-modularity-eg