[jsr294-modularity-eg] Nested superpackages

[Andreas Sterbenz]

Good to hear from you Matt. See comments below.

Matthew Flatt wrote:
>>
>> 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?

At the Java language level each type is uniquely identified by its fully 
qualified name. Fundamentally, the Java source language does not recognize 
multiple types with the same fully qualified name. This is something that 
an access control construct such as superpackages cannot and should not 
change.

Conceivably we could come up with some name mangling scheme that creates 
unique fully qualified names. For example, type a.b.c in nested 
superpackage x.y.z becomes x.y.z$$a.b.c. There are various complications 
with that, but the main problem is that this is a binary incompatible 
change. In other words, existing class files that refer to a.b.c would 
break after a.b.c is migrated to a superpackage. Since independent 
migration of components is important, we do not consider this to be 
acceptable.

That means what we have in the end is that a fully qualified name uniquely 
identifies a type in a superpackage and its nested superpackages. It 
follows that we can load all types using the same ClassLoader. Per Occam's 
razor, we should stick with one ClassLoader unless there is a good reason 
to use more than one. So far I have not heard a clear argument why 
multiple ClassLoader are required.

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

Great.

Andreas.