[jsr294-modularity-eg] Placing JSR 277 on hold

[Alex Buckley]

Hi BJ,

Thank you for reviving the public 294 list @ cs.oswego.edu. I agree we 
should use it in preference to the private jcp.org list.

BJ Hargrave wrote:
> So we are now 9 months later and getting back to work on JSR 294 which I 
> welcome. Given that so much time has elapsed since April 2008, we need 
> to have the current 294 design mailed to the EG to refresh our brains. 
> We need to set a baseline for our future discussions. When can this EG 
> expect to receive the latest 294 design document?

I will send a design document by the end of the month, including 
language syntax and semantics, classfile changes, and a discussion of 
how a module system interacts with the JVM. (This last part is analogous 
to section 5.3 of the JVM Spec, on how a user-defined classloader 
interacts with the JVM.)

Before that, I would like to scope the work of this EG. We agree that 
JSR 294 is not about a specific module system. It sits below a module 
system and allows a Java programmer to express certain concepts which 
are implemented by a collaboration of the JVM + a module system.

First among equals of these concepts is strong encapsulation: a way to 
group related packages so they can share data amongst themselves while 
hiding it from unrelated packages. Module membership and accessibility, 
both expressed with the 'module' keyword, provide such encapsulation.

The second concept is strong dependency: a type in one module can only 
refer to a type in another module if the requesting type's module 
expresses the appropriate dependency on the other type's module. I do 
not mean to pre-empt discussion about the appropriate granularity of a 
dependency, and it may be that JSR 294 can support both package 
dependencies and module dependencies. The critical point is that the 
observability of a type is determined at compile-time and run-time by 
first-class dependencies expressed in the requesting module.

(Observability is a concept expressed in the Java Language Spec [1] and 
deeply ingrained in javac. Today javac interprets it to mean "what's on 
the CLASSPATH". That will change. One hard topic that is if a type can 
be observable to another even without an explicit dependency at the 
module level, if a module system feature like re-export is surfaced in 
the language.)

Both these concepts rely on a third, that of module identity. Even 
though we should avoid embedding version numbers in Java class and 
variable declarations, it seems unlikely that we can keep versions out 
of dependencies. I will propose in the design document that a module 
identity is a (module name, module version) pair; that a module should 
have metadata to express its own version and those of its dependencies; 
and that the JVM should defer all questions of version structure and 
ordering to a module system.

I major on these fairly basic concepts because their understanding by 
millions of Java programmers is crucial. I hope that the nuances of how 
specific module systems handle identity, dependency, and observability 
can be simplified and abstracted when expressing them in the language.

> Unfortunately, in these last 9 months, any discussions that occurred 
> regarding this JSR (and 277) seem to have decayed into 1-way 
> communications (people blogging *at* others) and a number of 2-way 
> conversations (Sun speaking directly to individual EG members). This is 
> very disappointing. I feel we *must* return to having the discussions on 
> this JSR occur in the central mailing list for the EG (one N-way 
> communication amongst the EG members, and observable by the public). 
> This is necessary to have a healthy EG and produce a robust result 
> acceptable by all.

Agreed. Since 294 is not beholden to a specific module system (as 277 
was with JAM), I think EG communication will be much easier. In that 
vein, I want to reduce barriers to entry for all interested parties. 
When 294 was active in 2007, I and others received many private comments 
that deserved wider publication; recent announcements about JDK7 and the 
central role of modularity will stimulate more. JSR 166 famously 
benefited from defaulting to public discussion (+ a private EG list for 
decision-making), and JSRs 308 and 310 today are even more open.

My proposal is that the jsr294-modularity-observer at cs.oswego.edu list be 
made writable in itself, and that its membership of jsr294-modularity-eg 
be made writable too. Content coming from an -observer subscriber will 
be identifiable as such when crossing to the -eg list. I will make 
subscribing to -observer subject to admin approval.

These lists will remain separate from the Jigsaw OpenJDK list.

> I look forward to Sun's involvement at OSGi. Making sure the 294 design 
> is decoupled from Jigsaw such that all module systems can exploit it 
> will be best for Java. This is an excellent requirement for JSR 294.

I will attend the OSGi CPEG meeting next week in Boston. Of course 
Richard Hall is also there, so I guess I will mainly observe this time 
round.

> I think it is a bad idea to have the 294 discussion in the Jigsaw 
> mailing list. The Jigsaw mailing list should be for the purpose of 
> discussing Jigsaw which is not a JSR. JSR 294 discussions must not be in 
> the Jigsaw mailing list. As I see this, Sun is being quite clear 
> regarding the distinction between JSR 294 (a JCP JSR which is not 
> coupled to Jigsaw) and Project Jigsaw (which is an OpenJDK project that 
> will not be part of the Java 7 platform spec). Therefore, we must have 
> separate mailing lists to clearly separate these two efforts.

Conceded; see above.

> Until this mail was sent to JSR-294-EG at JCP.ORG, all prior 294 mail was 
> sent to jsr294-modularity-eg at cs.oswego.edu. It would be best to continue 
> with the original mail list since it will keep all the mail archived 
> together.

OK.

Alex

[1]http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.2