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

[Alex Buckley]

// 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