[jsr294-modularity-eg] Changes to the superpackage model

[Doug Lea]

Alex Buckley wrote:

> Second, I would like a yay or nay from EG members on the new design. 
> Please respond as soon as possible. Feedback from developers has been 
> very positive.
> 

I'm getting to like it. It does have the big advantage of having
a clearer path to success. A few stray minor concerns:

>>
>>    (It is not possible to make 'module M;' optional in these
>>    circumstances. In theory, a compiler switch can identify a class's
>>    module membership, but the JLS cannot talk about compiler switches;
>>    yet it must know module membership to determine accessibility.)
>>

It would be nice to hear from the IDE folks (Eclipse, Netbeans, Idea)
about prospects for helping developers semi-automate this. Offhand
it would seem almost trivial -- modules will often correspond to
"projects" in IDEs.


>>
>> - There are no nested superpackages. The EG has never supported them.
>>    I personally continue to support them, and think there is an
>>    interesting design space for nesting with decentralized module
>>    declarations. But it can be left for another day.
>>

I agree.

>> - super-package.class no longer appears as an authoritative member and
>>    export list. This is a non-issue in security terms, since the file was
>>    always trivially changeable.
>>
>> - module-info.class will be reified to support enumerating its
>>    annotations, but the 294 reflection API will not be able to enumerate
>>    a module's member and export lists. (Akin to how a package's member
>>    types cannot be enumerated.) Stanley Ho and I will work to simplify
>>    this API in general and unify it with 277's API.
>>

Similarly to above, tools and/or  IDE components will be needed
to maintain membership information, even if not directly
needed or required by JVMs. And again, I don't see anything precluding
it making it difficult. But it would be comforting to check
that there are no snags, especially in the following case:

>> - A JAM file in JSR 277 can be built by examining the classfiles named
>>    by the deployer (e.g. as parameters on the 'jam' command line):
>>    - The member list is available trivially.
>>    - The export list is the set of public types in the member list.
>>    - The import list is denoted by @Imports in module-info.java.
>>

(Using "@Import" strikes me as strange. Would either of
"import module" or "module import" work?)

-Doug




-Doug