[jsr294-modularity-eg] Placing JSR 277 on hold
Alex.Buckley at Sun.COM
Fri Jan 9 21:30:31 EST 2009
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  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
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
> 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
More information about the jsr294-modularity-eg