[jsr294-modularity-eg] 294 EG conf call, 2009-02-25

[Alex Buckley]

// EG members, feel free to add/edit points I haven't noted correctly.


* Attendees

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 [1], 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 
defineClass(..., moduleID).

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 [1] 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 [1] 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 [2] 
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 [3].

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.


Alex

[1]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-observer/2009-January/000002.html
[2]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-observer/2009-February/000073.html
[3]http://openjdk.java.net/projects/jigsaw/doc/api.html
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg