[jsr294-modularity-eg] Nested superpackages

[Glyn Normington]

Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 08/05/2007 07:46:25:

> 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.

Actually, the 'if' in "So if we really want JSR 294 to address the 
requirement exemplified by LUNI, [...]" was deliberate. You see I'm not at 
all convinced that this is a requirement worth the additional complexity 
of solving in JSR 294, given that JSR 291 fragments provide an existence 
proof of other ways to address this requirement.

> And let's 
> note that multiple types of the same name are not an issue for 
> java.lang/util/io.

Agreed, but that wouldn't necessarily be the case for the kind of large 
project nested superpackages are intended to support.

> 
> 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?

Neither. Matthew was on the right lines. There is an information hiding 
requirement that unexported class names in nested superpackages should not 
'clash'. This is a semantic rather than a syntactic issue - let's figure 
out the best semantics before we starting worrying how to spell it. ;-)

Glyn





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/20070508/bdf794d9/attachment.html