[jsr294-modularity-eg] Nested superpackages
Andreas.Sterbenz at Sun.COM
Wed May 30 19:33:31 EDT 2007
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
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
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.
More information about the jsr294-modularity-eg