[jsr294-modularity-eg] 294 EG conf call, 2009-02-25
Alex.Buckley at Sun.COM
Thu Feb 26 18:53:17 EST 2009
// EG members, feel free to add/edit points I haven't noted correctly.
Alex Buckley, Sam Pullara, Bryan Atsatt, Richard Hall, Michal Cierniak,
BJ Hargrave, Peter Kriens, Daniel Leuck, Doug Lea
* Issue tracking
While the EG continues to discuss requirements , the spec lead feels
that crystallizing phone and mailing list discussions into bug/issue
lists in JIRA or Bugzilla is not helpful. As discussions firm up, the
spec lead committed to a public wiki to list agreed requirements and the
resulting design decisions.
Bug reports against 294's Reference Implementation should be filed as
per the OpenJDK policy at https://bugs.openjdk.java.net/
* Peter's nested modules proposal
Peter's idea is that a "container" is the authoritative conferrer of
module membership. That is, module membership should be inferred only
from module-info.java, and that membership in package-info.java (or
individual source files) should be dropped.
(This is somewhat at odds with the previous week's discussion which
found "General support for module membership in package-info.java, and
in the main for module membership in individual source files." and
"General support for ... having the compiler get module membership for B
from a package-info file, which may or may not live in the same
directory tree as B.")
Peter's idea is further that only module-info.class would have a Module
attribute giving module membership. Normal classfiles would have
membership determined at compile-time based on their nearest enclosing
module-info.java/class, and at runtime based on a module system calling
A benefit of keeping the Module attribute out of normal classfiles is
that such classfiles were only ever going to contain module name and not
version. The question arises of whether module-private access control
should care about versions at compile-time. Comments welcome.
Where two types in the same package need to belong to different modules,
it is necessary to use arrange code into different containers. That is,
the source tree would be arranged with multiple roots, each with a
module-info.java/class to offer module membership.
General support for the container idea overall. However, some support
for the view that "operational approaches" (e.g. "compiler walks up the
directory hierarchy until it finds a file called...") are flawed; issues
with completeness and breadth-first/depth-first ordering.
Desirability of a nesting relationship between containers is an open
question. Comments welcome.
It follows that annotations should be allowed on the module declaration
in a container's module-info.java/class file.
Requirements 1-5 of  have all now received at least some discussion.
* Dependencies in source code
Peter's proposal envisioned module-info.java/class as containing a
module name only, without version or dependency information. Requirement
6 of  is that dependencies are expressible in source. This
requirement comes from the idea that developers know and should document
their own code's dependencies, notwithstanding BJ's comments in 
about the distinction between app provider and app assembler.
A lively discussion followed on the idea that a module's identity - name
and version - and its dependencies (other module identities) could be
expressed in source without committing the language to a particular
module system, version scheme, or dependency type (package v. module).
Some support for the feasibility of keeping versions (and perhaps names)
"opaque" in the language (requirement 13) and having them interpreted by
a module system (e.g. a build system or module library at compile-time
and a module-aware classloader at runtime).
The spec lead reaffirmed that the Jigsaw module system in JDK7 will not
be part of the Java SE 7 Platform, and that reference compiler and VM
will access a module system through a java.* API defined by this EG.
Prototyping is currently based on a simple draft API at .
Some support for the view that multiple module systems are inherently of
no interest to the developer, and that where they do exist, it might be
possible to define a subset of version/dependency concepts.
* Face-to-face meeting at EclipseCon in March
Monday 23 March, 12pm-evening, at Sun's Santa Clara campus.
Large room + breakout room reserved. LAN+wifi available.
* Next meeting
Wednesday 4 March. 10am US West, 1pm US East, 7pm France.
- Continue discussion of opaque dependencies in source.
- Discuss BJ's points about what features properly belong in the
language v. a module system.
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer