[jsr294-modularity-eg] 294 EG conf call, 2009-04-29

[Peter Kriens]

I miss one aspect. Bryan indicated that he wanted that the module  
system should be clearly indicated in the module-info file. I think BJ  
and I agreed with this and I heard no objections so I guess this was a  
majority view that included me :-)

I think it is important that people do not confuse Jigsaw with a  
default Java module system.

Kind regards,

	Peter Kriens


On 2 mei 2009, at 00:57, Alex Buckley wrote:

> // EG members, feel free to add/edit points I haven't noted correctly.
> // Apologies for these minutes being late. They also cover 2009-04-22.
>
>
> * Attendees
>
> Effective 2009-04-22, Bob Lee is Google's sole representative on the  
> EG. I thank Michal Cierniak for his long-term involvement in JSR 294.
>
> 2009-04-22:
> Alex Buckley, Bryan Atsatt, BJ Hargrave, Peter Kriens, Bob Lee,
> Sam Pullara, Richard Hall
>
> 2009-04-29:
> Alex Buckley, Bryan Atsatt, BJ Hargrave, Peter Kriens, Bob Lee,
> Daniel Leuck   (Apologies: Richard Hall)
>
>
> * Reference Implementation
>
> The RI of JSR 294 is hosted by the OpenJDK Jigsaw project:
>
>  http://openjdk.java.net/projects/jigsaw/
>
> The OpenJDK Jigsaw project hosts both the RI of JSR 294 (javac and  
> Hotspot) and the implementation of the Jigsaw module system. This is  
> analogous to the OpenJDK Compiler project, where javac lives long- 
> term. The Compiler project hosts a single codebase that consists of  
> the RI of the Java language and an implementation of a library  
> mechanism called 'classpath'. 'classpath' does not appear in the  
> spec of the language, but naturally its code lives near the RI of  
> the language.
>
> Additions to the java.* hierarchy are proposed for the RI:
>
>  http://cr.openjdk.java.net/~mr/jigsaw/api/
>
>
> * Recap of EG agreements w.r.t. accessibility
>
> - Runtime modules should be able to span classloaders, allowing OSGi  
> to
>  offer strong encapsulation across multiple bundles.
>
> - Module membership should not appear in source and classfiles,  
> allowing
>  OSGi to infer it based on membership in deployment artifacts.
>
> - Module-private members should be allowed in interfaces.
>
> - 'package' should be allowed as an accessibility modifier.
>
>
> * Module dependencies
>
> The conference calls of 2009-04-{22,29} saw a tremendous amount of  
> free-flowing discussion. I believe the main questions were: (along  
> with the *majority* EG view for each answer)
>
> - Does the EG want to define a 'module compilation unit' in the Java
>  language, and a corresponding binary representation as a classfile?
>  Yes. (The JLS will not fix filenames.)
>
> - Does the EG want a module compilation unit to have multiple  
> sections,
>  each containing information specific to a particular module system?
>  No.
>
> - Assuming that a module compilation unit contains information for one
>  module system only, does the EG want a module compilation unit to
>  always identify that module system?
>  Yes.
>
> - Does the EG want to agree on universal modularity concepts that
>  deserve their own keywords in a module compilation unit?
>  Yes. BJ explored this at [1] and Bryan gave syntactic options at [2].
>
> - Does the EG agree that a dependency of one module on another element
>  (e.g. another module, package, resource, etc) is sufficiently
>  important to justify a 'requires' keyword?
>  Yes.
>
> - Does the EG agree that a description of what one module provides to
>  other modules (e.g. exported packages in OSGi or module aliases in
>  Jigsaw) for use in dependencies is sufficiently important to justify
>  a 'provides' keyword?
>  Yes.
>
> - Does the EG agree that a reverse dependency, where one module
>  describes which other modules may express a dependency on it, is
>  sufficiently important to justify a 'permits' keyword?
>  No.
>
>
> * Next meeting
>
> Wednesday 6 May. 10am US West, 1pm US East.
>
> - Specifying module dependencies
> - Plans for EDR and J1
>
>
> Alex
>
> [1]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-May/000277.html
> [2]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-April/000275.html
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg