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

[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-01.


* Attendees

Alex Buckley, Bryan Atsatt, BJ Hargrave, Peter Kriens, Bob Lee,
  Sam Pullara, Daniel Leuck
Apologies: Richard Hall


* Module membership in source/class files

The EG had a long discussion over whether compilation units and 
classfiles should declare their module membership. Alex was concerned 
that dropping module membership from source would cause difficulties for 
access control when compiling multiple modules together.

Subsequently, Alex and the javac tech lead conducted a thorough analysis 
of how javac, as the Reference Implementation of a compiler for the Java 
programming language, could find and compile multiple modules. The 
analysis is introduced at [1] and the findings are at [2].

During this analysis, Alex concluded that, on balance, module membership 
should NOT be represented in compilation units or classfiles. (Except 
for module compilation units and corresponding classfiles, obviously.) 
This aligns with the majority EG view on the subject.

The EG supports module compilation units. A module compilation unit 
contains a module declaration that may be annotated. Some EG members are 
interested in allowing types to be declared in a module compilation unit 
for the purpose of "module-global" constants. On a filesystem, a module 
compilation unit is conventionally a module-info.java/class file.


* Module dependencies in source/class files

The EG is split over whether it should be possible to denote a module's 
dependencies in a first-class way, using keywords within a module 
declaration in a module compilation unit. It is always possible to 
denote dependencies using annotations on a module declaration, which a 
particular module system can inspect.

Regardless of denotation, there is general support for a requirement 
that dependencies indicate which module system must interpret them.

Bob pointed out that listing dependencies at the module level means the 
programmer has to track which classes in a module are responsible for 
each dependency. He proposed allowing dependencies in individual 
compilation units, though this burdens compilers and module systems with 
ensuring that a module has visibility over a consistent set of types.


* Next meeting

Wednesday 15 April. 10am US West, 1pm US East.

- Module dependency syntax and semantics
- Plans for EDR and J1


Alex

[1]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-April/000076.html
[2]http://openjdk.java.net/projects/jigsaw/doc/ModulesAndJavac.pdf

_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg