[jsr294-modularity-eg] 294 EG conf call, 2009-06-17
neal at gafter.com
Wed Jun 24 02:03:16 EDT 2009
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
> 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
> 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.
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jsr294-modularity-observer