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

[Eugene Vigdorchik]

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 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.

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