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

Alex Buckley Alex.Buckley at Sun.COM
Thu Apr 3 19:43:59 EDT 2008 

Bryan Atsatt wrote:
> Obviously I'm all in favor of this model. Some thoughts:
> 
> 1. This implies that the 'module' qualifier can be used for *members* as 
> well. In particular, it would be possible to have:
> 
>    public class Foo {
>        public static final String A_PUBLIC_CONSTANT = ...
>        module static final String A_MODULE_PRIVATE_CONSTANT = ...
> 
>        public void aPublicMethod() {...}
>        module void aModulePrivateMethod {...}
>    }
> 
> (IMO, this is a very nice advantage of this model over superpackages.)

Absolutely!

> 2. While I understand that the JLS cannot talk about compiler switches, 
> I strongly believe that we should find a way to define module membership 
> at this level such that 'module M;' at the source level is supported but 
> not required: a compiler switch makes for a vastly easier migration to 
> modules.

I had some further thoughts on where to declare module membership in 
source code:
http://blogs.sun.com/abuckley/en_US/entry/module_membership_declarations

After writing that piece, I began to think we should allow membership 
declarations in either package-info or normal compilation units. 
(Obviously if you use both, the compiler will require consistency.) 
package-info is very popular in private comments I receive.

But Jon Gibbons, the javac lead, points out a difficulty with 
package-info: javac only sees package-info when invoked with 
-sourcepath. Given:
   P/
     package-info.java
     C.java
if you say:
   javac P/C.java
then P/package-info is invisible - javac has no concept of "current 
directory". Nor does the JLS talk about such a concept, except 
grudgingly in the discussive section on package-info.

So the benefit of declaring module membership once in package-info is 
reduced by the need for -sourcepath on every compilation. If we're 
having a switch, let's just have:
   javac -defaultmodule:M P/C.java
and say that if a compilation unit doesn't declare a module itself, then 
the default module determined by the "host system" (a concept introduced 
by JLS 7.3) is where the unit lives.

> Further, we should consider migration of modules from existing module 
> systems. It will be quite natural for OSGi, for example, to perform 
> *runtime* mapping of member classes via bytecode manipulations: 
> injecting the module name and setting the ACC_MODULE flag. We have the 
> option of introducing APIs to make such mappings fully supported.

Yes. I'm still working with Stanley on the reflection API, so let me get 
back to you on that. Also, I hope BJ will comment on this topic and the 
new model in general.

Alex

> // Bryan
> 
> Alex Buckley wrote:
>> 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

More information about the jsr294-modularity-eg mailing list