Alex.Buckley at Sun.COM
Tue Sep 18 17:09:57 EDT 2007
Rok Strnisa wrote:
> On 18 Sep 2007, at 21:05, Alex Buckley wrote:
>> The paper raises two issues:
>> 1) Sharing a type between two module definitions.
>> 2) Selecting a type in a module definition when import policy and
>> artifacts cause multiple types with the same name to be available.
>> From a 294 perspective, these issues do not arise because of the rule
>> that a type can only be a member of a single superpackage. Indeed, the
>> rule was expressly designed to keep things simple for a Java
>> who just wants to group related packages together.
> The paper deals with _different_ types that are present in different
> superpackages (module definitions), but have the same fully-qualified
> names, either accidentally or on purpose (to override the other type).
Right, for 'type' I should have written 'type definition'.
> Do you mean by "a type can only be a member of a single superpackage"
> a) "each fully-qualified class name can only appear as a member in a
> single superpackage", or
> b) "an exact type (represented by an exact classfile) can only appear
> as a member in a single superpackage"?
> If a), the decision seems too limiting; if b), the decision does not
> interfere with the idea in the paper.
(b). Superpackages don't talk to each other to limit a type name to one
definition per VM. You can copy a classfile and modify the copy's
superpackage information; the two type definitions have the same FQN but
are in different superpackages statically and dynamically.
More information about the jsr294-modularity-eg