[jsr294-modularity-eg] Changes to the superpackage model
dl at cs.oswego.edu
Thu Apr 3 06:35:04 EDT 2008
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.
>> - 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?)
More information about the jsr294-modularity-eg