[jsr294-modularity-eg] 294 EG conf call, 2009-05-13

[Alex Buckley]

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


* Attendees

Alex Buckley, BJ Hargrave, Peter Kriens, Richard Hall, Bryan Atsatt,
   Bob Lee, Daniel Leuck, Doug Lea


* JavaOne meeting

Afternoon of Monday June 1. Bob offered to host at Google near Moscone. 
This is ideal since the PMO's Moscone room is unavailable on Monday.


* Module dependencies

The EG agrees that a mechanism to statically validate dependencies in a 
module compilation unit is desirable. Bob pointed out a spectrum of 
responsibility for doing the validation:

   Compiler only / Compiler + Module system / Module system only

Unless the JLS defines its own module system (which it doesn't), a Java 
compiler is limited in what it can validate. Notably, validating joint 
constraints on multiple dependencies can only be done by a module 
system. (Two 'requires' with different exact versions of the same target 
is almost certainly invalid.) Therefore, the only realistic points on 
the spectrum are compiler + module system, and module system only.

The EG then reviewed Bob's module directive types [1] which allow the 
compiler to make a significant contribution to validation. For example, 
Bob used enums to restrict the values of operands:

   // Definition
   public enum Granularity { PACKAGE, BUNDLE; }
   public @module export {
     String name();
     Granularity granularity() default Granularity.PACKAGE;
     String version();
   }

   // Use
   import static Granularity.*;
   module M {
     import name: "P" granularity: BUNDLE version: ">1.0";
   }

As a schema language (or metatheory, as Doug put it), module directive 
types share some restrictions of annotation types: optional operands 
cannot be expressed (default values may not be appropriate in this 
domain) and deep structures such as versions are unwieldy to define and 
use (akin to @Version(@Major(".."), @Minor(".."), @Qualifier("..")).

Peter (and to a lesser extent, Doug) supported Bob's use of a schema 
language to allow a compiler to partially validate a module compilation 
unit. Bryan and Alex disagreed, taking the position that validation is 
too large a problem to be solved without significant module system help, 
and too small a problem to justify a whole schema language which only a 
handful of module system designers will ever write in.

Bryan also believed it was a disservice to users if module directive 
types allowed dependencies for different module systems in the same 
compilation unit, as Bob's example showed.

The majority view of the EG was that a compiler should not attempt to 
use schema definitions to validate some aspects of a dependency; and 
that a compiler should validate all aspects of a dependency via a module 
system API.

Discussion turned to extensible syntax, which a majority of the EG 
supports. Bryan aimed for the syntax of extended operators like 
'classpath' to look identical to JLS-defined operators like 'requires'.

Daniel was sceptical: rather than freedom of choice, it's better to have 
freedom FROM choice since users won't know what they're reading or 
writing. Richard echoed this belief. However, since the majority of the 
EG supports a 'system' identifier, a user reading or writing 
dependencies can always predict how they will be interpreted. Bob 
proposed that 'system' lexically appear before dependencies.

BJ reiterated that a module compilation unit is a DSL and that IDEs 
already process non-Java DSLs, so a Java source file is unnecessary. 
Bryan stated that an IDE could parse Java source as easily as any other 
DSL, and further that Java source allows annotations. Use cases for 
annotations include invariants (in the module compilation unit) on the 
expected properties of a module at runtime, and generated data (in the 
classfile) that reify exactly how a dependency was resolved previously. 
Alex stated that annotations on every element in a module compilation 
unit (not just the module declaration itself) is the eventual goal but 
unlikely in the JDK7 timeframe [3].


* Next meeting (the last before J1)

Wednesday 20 May. 10am US West, 1pm US East.

- ModuleInfo API derived from syntactic elements of a dependency. [2]


Alex

[1]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-May/000285.html
[2]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-May/000292.html
[3]http://openjdk.java.net/projects/jdk7/milestones/