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

[Alex Buckley]

Hi Eugene,

Eugene Vigdorchik wrote:
> Hello,
> I really like the new proposal better. To make for a seamless adoption, I think the following should be taken into consideration:
> - 'module' should be made a restricted keyword outside of class declaration. This should not be a problem since module membership
> will be defined per compilation unit.

'module' is a restricted keyword everywhere in a compilation unit. You 
want 'module M;' outside a class declaration AND 'module String s;' 
inside a class declaration to work.

In fact, this code has to be possible:

module module;
module class module {
   module module module = new module();
}

The realization that an identifier is a restricted keyword will have to 
be done in different ways outside and inside a class declaration. 
Outside, the first "module" term parsed means the start of a module 
declaration. Inside, for member declarations, the rule is: if "module" 
appears before the last two identifiers in the member declaration, it is 
a modifier; otherwise it is an identifier.

static module f;
   // Modifier Identifer Identifier -> Modifier Type Identifier
module int f;
   // "module" Identifier Identifier -> Modifier Type Identifier
module module f;
   // "module" Identifier Identifier -> Modifier Type Identifier

> - module declaration _should_ be made optional, i.e. it would only be needed when there are explicit refererences to module-private
> declarations. I don't like the idea of carrying module declarations over from IDE projects the user has set up for all the
> compilation units. One could of course have an intention action (suggestion from the IDE) to restrict certain class to current IDE
> project only, but definitely not for all files.

If a type is itself not module-private in any way, and does not use any 
module-private types or members, then there is no need for the type (or 
the compilation unit it is in) to be a module member.

Whether you map an IDE project to a language module is up to you ... it 
sounds like you want a project to contain many compilation units, some 
of which declare module membership and some of which may not. Yes?

Alex

> Eugene
> 
> -----Original Message-----
> From: jsr294-modularity-eg-bounces at cs.oswego.edu [mailto:jsr294-modularity-eg-bounces at cs.oswego.edu] On Behalf Of Alex Buckley
> Sent: Thursday, April 03, 2008 3:47 AM
> To: JSR 294 Expert Group
> Subject: Re: [jsr294-modularity-eg] Changes to the superpackage model
> 
> First, I must correct a major oversight in the mail below. Bryan Atsatt's mails in February on the undesirability of separate "294
> modules" and "277 modules" were instrumental in getting the new design off the ground, and I thank him for numerous discussions
> behind the scenes on module membership and reflection.
> 
> 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.
> 
> Alex
> 
> Alex Buckley wrote:
>> I propose a change to the nomenclature and design of superpackages.
>>
>> JSR 294 has so far aimed to minimize syntactic changes in existing 
>> source code, at the cost of redefining the semantics of 'public'
>> according to a separate compilation unit (super-package.java).
>>
>> There are some problems with that aim:
>>
>> - Redefining an existing access modifier is not respectful of millions
>>    of developers' investment in the traditional accessibility model of
>>    the Java platform. I say "platform" not "language" because redefining
>>    'public' means redefining the ACC_PUBLIC flag in a classfile, and that
>>    affects every non-Java language compiler targeting the JVM.
>>
>> - Minimizing changes in existing source code is not respectful of the
>>    Java language principle that "Reading is more important than than
>>    writing". To save one developer from writing 'superpackage S;' in
>>    a source file, we impose a burden on every subsequent developer who
>>    reads the source file and wants to reason about accessibility.
>>
>> - Even if a separate export list is thought desirable (and it surely
>>    has a valuable documentary role), it is insufficient to have only
>>    simple regexs ('export foo.*'). A discussion thus starts about
>>    what regexs the JLS should support, which is frankly a distraction
>>    from bigger issues and provides yet more complexity for a developer
>>    trying to determine what is accessible.
>>
>> My proposal:
>>
>> - Retain the current meaning of 'public' and ACC_PUBLIC.
>>
>> - Introduce a 'module' access modifier for types and members. A new
>>    ACC_MODULE flag (0x8000) reifies module accessibility in a classfile.
>>
>> - Require any compilation unit whose types are 'module'-private or
>>    access module-private types/members, to identify their module
>>    membership via a single 'module M;' declaration.
>>
>>    (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.)
>>
>>    A classfile has a Module attribute to reify module membership.
>>
>> - Since globally public types are 'public' and module-private types are
>>    'module' qualified, there is no need for super-package.java. Only if
>>    module-level annotations are used does the following file, analogous
>>    to package-info.java, come into play:
>>
>>    // This file is M/module-info.java and compiles to M/module-info.class
>>    @Foo
>>    @Version(...)
>>    @Imports(...)
>>    module M;
>>
>> Implications of the proposal:
>>
>> - 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.
>>
>> - super-package.class no longer needs to be regenerated when a new type
>>    is added to a package P and 'export P.*;' is in super-package.java.
>>
>> - super-package.class no longer needs to be read by the VM when loading
>>    a class. A classfile's accessibility is completely self-described.
>>
>> - 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.
>>
>> With this proposal, a module in JSR 294 continues to be the foundation 
>> of a module in JSR 277, but getting started with just a 294 module is 
>> now easier because the 'module' modifier is a simple and consistent 
>> extension of the traditional accessibility model (in line with the 
>> second goal of the 294 strawman). Comments are welcome.
>>
>> Alex
>> _______________________________________________
>> jsr294-modularity-eg mailing list
>> jsr294-modularity-eg at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
> 
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg