[jsr294-modularity-eg] 294 EG conf call, 2009-04-15

[Alex Buckley]

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


* Attendees

Alex Buckley, Bryan Atsatt, BJ Hargrave, Peter Kriens, Bob Lee,
  Daniel Leuck
Apologies: Richard Hall, Michal Cierniak


* Module dependencies in source/class files

Everything there is to be said about the use of annotations for 
dependencies has been said. Representing multiple dependencies requires 
contortions, and a compiler is required to identify special annotation 
types to decode dependency annotations. This is a problem when types are 
no longer found on a global classpath. It is cleaner for a compiler, and 
easier to read for a developer, if dependencies are read and written in 
the language. Peter's objection is noted.

Bryan proposed a syntax for 'requires' based on name:value pairs, e.g.

module M @ 5.0 {
   requires module:N  version:"1.0+" optional:true;
   requires package:P version:"(1.0,2.0]";
   permits  module:O;  // Module O is M's friend
   permits  anyoneWhoRequires:4.5+;  // M v5.0 is compatible with 4.5+
}

Bryan also proposed that a module-info.java file should belong to one 
module system only. There is a terrible loss of clarity and coherence if 
one file contains multiple sets of dependencies each with their own 
granularity (module/package/service) and version scheme. Dan agreed that 
context-sensitive dependencies were undesirable.

Some suggestions for how to denote the "owning" module system of a 
module compilation unit are:

1) module M @ 5.0 {..}  then  javac -modulesystem osgi module-info.java

2) osgi module M @ 5.0 {..}

3) module M @ 5.0 { system osgi @ 4.2; requires package ... }

Denoting the owning module system is optional. The resulting classfile 
has an optional attribute (probably documented in the JVM Spec) denoting 
the owning module system.


* Next meeting

Wednesday 22 April. 10am US West, 1pm US East.

- Module dependency syntax and semantics
- Plans for EDR and J1


Alex