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

[Neal Gafter]

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> 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
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090623/e3a0f689/attachment.html>