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

[Alex Buckley]

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


* Attendees

Alex Buckley, BJ Hargrave, Peter Kriens, Richard Hall, Bob Lee, Doug Lea


* Module dependencies

Alex mentioned that options 3 and 4 of [1] give unduly small prominence 
to the target of a dependency, which will always be present. If 
granularity gets its own term, then the name+version of the target 
should too. (The old 'requires GRANULARITY ... NAME @ VER ...' form.)

[1]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-April/000275.html

There was some support for designing a scheme to encode the schema of a 
module system, i.e. the legal operands and parameters of its 
dependencies. The aim is to let a compiler/IDE connected to a module 
system validate a dependency, for example rejecting 'requires pakcage 
...' and 'requires ... copyrite=...'.

Bob, Doug, and Peter looked to annotation types for inspiration on how 
to enumerate valid operands and their types. Consider something like:

   @interface Requires {
     String   granularity();
     String[] modifiers;
     String   name();
     String   version();
     String[] keys();
     String[] values();
   }

Annotation types are inadequate for this task because they:
- cannot express optional members (modifiers is the obvious candidate) ;
- cannot express restricted combinations of members ("only allow the 
'dynamic' modifier with the 'package' granularity", "only allow a 
copyright key if there's a vendor key") ;
- assume that each member maps directly to the member of an annotation, 
whereas keys() and values() obviously need to be indirect; an annotation 
doesn't literally want to say ...keys="A,B",values="X,Y"... ;
- cannot encode the semantics of values.

The last restriction is the biggest. If a version "[2.0,1.0)" is 
semantically invalid in a module system (and it probably is), then a 
compiler/IDE should reject it. No extension of annotation types, or any 
other static schema language, can reasonably support this evaluation.

I believe the full logic of a module system is needed to evaluate a 
dependency's operands, even if an IDE - as the module system's client - 
actually displays the errors as you type. Only through an API can a 
module system be called upon to validate a dependency's modifiers, 
target, and other standard syntactic elements such as key:value pairs.

(In general, an API could do more; consider a module system that takes a 
version range for a required module, resolves it against a library, and 
suggests the best specific version to embed in the module compilation unit.)


* Next meeting

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

- Specifying module dependencies
- Plans for J1


Alex