[jsr294-modularity-eg] 294 EG conf call, 2009-06-17

[Alex Buckley]

Ignoring the fact that module-related annotations DO affect the meaning 
of a program (by causing one definition of a given type to be used 
rather than another), there are plain expressability problems such as no 
repeating annotations and no recursion. Examples on this list that 
expressed realistic dependencies with annotations were cumbersome.

This topic is done.

Alex

Neal Gafter wrote:
> Why is an "extensible syntax" preferred to annotations?  Annotations are 
> already extensible, and (like annotations) these extensions do not 
> affect the compile-time or runtime semantics of Java program elements.  
> I would expect that annotations are a perfect fit for this use.
> 
> On Tue, Jun 23, 2009 at 6:46 PM, Alex Buckley <Alex.Buckley at sun.com 
> <mailto:Alex.Buckley at sun.com>> wrote:
> 
>     * Attendees
> 
>     Alex Buckley, BJ Hargrave, Peter Kriens, Richard Hall,
>     Bryan Atsatt, Doug Lea
> 
> 
>     * Decisions from the JavaOne face-to-face meeting
> 
>     - Alex to send a simplified API for java.lang.reflect.Module & friends.
>     - No module-private members in interfaces.
>     - Tentatively, allow the 'package' keyword as an access modifier.
> 
> 
>     * Module compilation units
> 
>     The EG agreed that the syntax of a module declaration in a module
>     compilation unit (a.k.a. module-info.java) should be extensible.
>     That is, have a generic grammar without fixed keywords for concepts
>     such as dependencies.
> 
>     A long discussion was held over whether a module system could ignore
>     directives it didn't like, and how a compiler or runtime with
>     multiple module systems available would choose which owns a given
>     module-info.java/class.
> 
>     The EG agreed there should be a reserved keyword (notionally
>     'system') for identifying the module system, but that it should be
>     optional in source. There was slightly more support for having the
>     keyword live outside the body of the module declaration than inside it.
> 
>     There would be at most one directive for identifying the module
>     system allowed. BJ pointed out that bundles often have a manifest
>     which uses OSGi-spec headers and Eclipse-custom headers, and so
>     require more than the 'standard' OSGi module system. The analogue in
>     module-info.java is writing (something like) 'system osgi+eclipse'.
>     If a programmer really wants to write a module resolvable in
>     radically different module systems, then they'd write (something
>     like) 'system osgi/jigsaw' and it would be up to a module system
>     facade to interpret that.
> 
> 
>     * Next meeting
> 
>     Wednesday 1 July. 10am US West, 1pm US East.
> 
>     Unfortunately I cannot do a call this Wednesday, 6/24/09. I will
>     send the unified language, classfile, VM, and API specs to the EG by
>     the end of this week, 6/26/09.
> 
> 
>     Alex
>     _______________________________________________
>     jsr294-modularity-eg mailing list
>     jsr294-modularity-eg at cs.oswego.edu
>     <mailto:jsr294-modularity-eg at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
> 
>