[jsr294-modularity-eg] Nested superpackages

[Matthew Flatt]

At Mon, 07 May 2007 23:46:25 -0700, Andreas Sterbenz wrote:
> Glyn Normington wrote:
> > 
> > So if we really want JSR 294 to address the requirement exemplified by 
> > LUNI, should we not see whether there is a better information hiding 
> > approach than the current nested superpackage proposal? For instance, 
> > has class name prefixing being considered, along the same lines that 
> > were used for nested classes to prevent unexported classes clashing 
> > unexpectedly?
> 
> Good to hear that you agree that this is an issue we need to address and 
> that java.lang/util/io is a good example of the requirements. And let's 
> note that multiple types of the same name are not an issue for 
> java.lang/util/io.
> 
> Do you feel that there is some information hiding requirement exemplified 
> by java.lang/util/io that is not addressed by the nested superpackage 
> proposal? Or is it the current syntax for nested superpackage that is the 
> cause of your concern?

I have finally caught up with the dicussion, and I'm generally in favor
of nested superpackages.

The requirement that all class names are unique across nested
superpackage seems awkward to me, though --- and that's what I thought
Glyn was thinking of. Although it's not a problem for
java.lang/util/io, it's still not clear to me why the constraint is
needed. To put it another way, is it crucial that a top-level
superpackage is implemented by exactly one classloader, and that no
class names are changed in a .class file compared to the way things
work now?

In any case, the requirement doesn't bother me enough to turn me off
nested superpackages.

Matthew