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

Peter Kriens peter.kriens at aqute.biz
Wed Jun 24 13:06:47 EDT 2009


I wont be able to make the call, stuck on CDG :-(

Kind regards,

	Peter Kriens

On 24 jun 2009, at 03:46, Alex Buckley 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



More information about the jsr294-modularity-eg mailing list