[jsr294-modularity-eg] 294 EG conf call, 2009-04-08
Alex.Buckley at Sun.COM
Fri Apr 10 19:53:25 EDT 2009
// 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.
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  and the findings are at .
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
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer