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

[Bryan Atsatt]

Here's Alex's example reformatted to use the category operand I 
suggested on this morning's call, with an additional "export" declaration.

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

    provides package "m"; // Exports package 'm'
}

// Bryan

Alex Buckley wrote:
> // 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
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>