March 2017 - java-se-9-spec-observers

Re: Question regarding the "Modular platform"
by mark.reinhold＠oracle.com 05 May '17

05 May '17

Volker originally sent this to the java-se-9-spec-comments list, but now that he's on the EG I figured I'd just reply here. 2017/2/22 10:04:26 -0800, volker.simonis(a)gmail.com: > referring to the "Java SE 9 (JSR 379) Early Draft Review > Specification" I'd like to get some clarifications regarding the > definition of the "Modular platform" and its implications on > implementors of Java SE 9. > > Section "7 Modular platform" of the specification starts with the > statement that it "..uses the Java Platform Module System, specified > by JSR 376, to modularize the Java SE Platform". One of the goals is > to "Divide the Java SE Platform into a set of modules that can be > combined at compile time, build time, or run time into a variety of > configurations including, but not limited to..Custom configurations > which contain only a specified set of modules and the modules > transitively required by those modules." > > What is "compile time, build time, or run time" referring to? Is it > the "compile time / build time" of the platform itself? No, it's referring to those phases in the development of a library or application that runs on top of Java SE 9. > I.e. should it > be possible for an implementor to only build and assemble a subset of > the standard modules into his "Java SE Platform"? That's a different question, and the answer is "yes". > And will this still > be called "Java SE 9"? Yes, that's the intent. > Later on, in the "Conformance" section, the specifications mentions > that "Every Implementor of this Specification must implement the > java.base module. Every Implementor may, further, implement a set of > one or more additional standard SE modules so long as that set is > closed, i.e., contains every standard module required by any member of > the set.". > >> From this and the previous statement I would expect that an > independent implementor as well as an OpenJDK distributor could build > a "Platform implementation'" which only contains the java.base module, > certify that with the Java SE 9 TCK (because "The Technology > Compatibility Kit (TCK) for this Specification will be structured to > allow testing of arbitrary configurations of SE modules present in a > Platform Implementation.") and provide that to its customers. Is that > correct? Yes, that's the intent. > And if it is correct, how could a user of such a "Platform > implementation" distinguish two different implementations which > provide a different subset of standard modules? Currently, as far as I > can see in the RI, running "java -v" always identifies itself as > "Java(TM) SE Runtime Environment (build 9-ea+xxx)", no difference > which modules it contains. The user would have to run "jimage list" > on the modules file to find out which modules are included (not to > mention that "jimage" isn't a standard tool anyway). The Java SE Platform Specification has never specified command-line tools, so there's no such thing as a "standard" tool. >From a pure SE perspective, you can distinguish implementations that contain different sets of modules by examining the set of modules in the boot layer via the API: java.lang.reflect.Layer.boot().modules().forEach(System.out::println); >From the command line, the RI supports a `--list-modules` option that does much the same thing. > That said, the "Goals" section also mentions that "standard modules > that are part of the Java SE Platform Specification, and thereby > mandatory in every Platform Implementation" which seems to contradict > with the above points which explicitly allow sub-setting (as long as > that set is closed). That text is incorrect -- the "mandatory" clause should be removed. Thanks for catching this inconsistency. > Finally, it would be good to have a new version of the "OpenJDK > Community TCK License Agreement" (OCTLA) available BEFORE the final > vote on JSR 379. I understand that standardization and licensing are > two different things. But first, JSR 379 explicitly references the TCK > and second voting on a new standard which technically allows > sub-setting and modularization is pointless if these new possibilities > would be prohibited by licensing. At least the current OCTLA [1] > explicitely states that a "Compatible Licensee Implementation" has to > "..fully implements the Java Specification, including all its required > interfaces and functionality..". Work on an updated OCTLA is in progress. - Mark

2 3

Custom configurations and definition of "closed set"
by Simonis, Volker 26 Apr '17

26 Apr '17

Hi, the public review version of the Java SE 9 spec [1] mentions in the "Goals" section that it allows "Custom configurations which contain only a specified set of modules and the modules transitively required by those modules". Later on in the "Conformance" section it specifies that "every Implementor may, further, implement a set of one or more additional standard SE modules so long as that set is closed, i.e., contains every standard module required by any member of the set". This sentence is unclear, because it doesn't seem to make a distinction between "required" and "transitively required". According to the "Goals" section (and the "modular graph" picture) I think this sentence should read "..contains every standard module TRANSITIVELY required by any member of the set". But even with the corrected wording, this can lead to a situation where one Implementor's concrete "closed" subset of a valid "custom configuration" contains different/additional standard modules compared to the concrete "closed" subset of another Implementor's implementation of the same "custom configuration". As an example, imagine that implementor A implements a "java.desktop" configuration. According to the specification he also has to implement "java.xml", "java.datatransfer" and "java.base" because these three modules are all in the transitive closure of "java.desktop" (with regard to the "requires transitive" relation). A second implementor B also implements "java.desktop", but he decides to use "java.logging" in his implementation of the "java.desktop" module. So he "requires" (non-transitively) "java.logging" in "java.desktop". Implementor B's "java.desktop" configuration will now contain "java.logging" while implementor A's implementation of the same configuration will not contain "java.logging". 1. Are both, A's and B's, implementations of "java.desktop" standard conforming? The "Conformance" section also states that "The Technology Compatibility Kit (TCK) for this Specification will be structured to allow testing of arbitrary configurations of SE modules present in a Platform Implementation". 2. What will be the scope of the TCK testing for a "closed" subset? Will it be the set of "transitively required" modules as mandated by the standard or will it be the, usually bigger, set of actually required modules of the concrete implementation? So in the previous example, will the TCK test for the "java.desktop" configuration also test "java.logging" for implementor B's implementation of the "java.desktop" configuration? 3. Finally, am I right with my assumption that only the "requires transitive" relation between modules is governed by this specification and the JCP? Or, in other words, is every Implementor free to add an arbitrary number of simple "requires" relations from one standard module to other standard modules at his discretion (assuming he will not introduce dependency cycles)? Regards, Volker [1] http://cr.openjdk.java.net/~iris/se/9/java-se-9-pr-spec-02/java-se-9-spec.h…

2 1

Mandatary nature of standard Java SE modules
by Simonis, Volker 26 Apr '17

26 Apr '17

Hi, in a previous conversation (see below) I objected the wording in the "Goals" section which stated that "standard modules that are part of the Java SE Platform Specification" are "mandatory in every Platform Implementation". You agreed and removed that sentence from the latest 'public review' version of the specification. While digging deeper into the specification, I found a similar phrase in subsection 4 of the "Design principles" section which states that "If a standard module is a Java SE module, i.e., is mandated by this Specification, then it must not export any non-SE API packages, at least not without qualification". I think the subsentence ".. i.e., is mandated by this Specification .." should be removed because the specification doesn't mandate all Java SE modules. Thank you and best regards, Volker > > That said, the "Goals" section also mentions that "standard modules > > that are part of the Java SE Platform Specification, and thereby > > mandatory in every Platform Implementation" which seems to contradict > > with the above points which explicitly allow sub-setting (as long as > > that set is closed). > > That text is incorrect -- the "mandatory" clause should be removed. > Thanks for catching this inconsistency.

2 1

Java SE 9 PR Specification posted to jcp.org
by Iris Clark 21 Mar '17

21 Mar '17

FYI: https://jcp.org/en/jsr/detail?id=379 The review period ends Thu 20 Apr. Thanks, Iris

1 0

Java SE 9 (JSR 379) Public Review Specification (DRAFT 2)
by Iris Clark 10 Mar '17

10 Mar '17

Hi. The second draft of the Public Review Specification is available here: http://cr.openjdk.java.net/~iris/se/9/java-se-9-pr-spec-02/java-se-9-spec.h… This draft includes the following minor changes: - Spec: Section 4: Add references to specific Maintenance Releases to JSRs 199, 221, and 269. Remove reference to JSR 907. - Spec: Section 7, Goals subsection: Remove "mandatory" clause from final sentence in the subsection. - Spec: Section 10: Change module name from "java.annotations.common" to "java.xml.ws.annotation" matching the existing module graph. - Annex 2: Provide diffs against recent build 160 promotion. Remove jquery/* packages from overview-summary.html. The deadline for comments before I submit this to the JCP PMO for formal Public Review is unchanged. Please let me know by 17:00 UTC next Tuesday, 14 March, if you believe changes are required, or you need additional time for review. Thanks, Iris

1 0

RE: Java SE 9 (JSR 379) Public Review Specification
by Iris Clark 08 Mar '17

08 Mar '17

Hi, Remi. Thanks so much for reading the Spec and reporting this problem. I've replaced all references to "java.annoations.common" to "java.xml.ws.annotation" in my working document. Thanks, iris -----Original Message----- From: Remi Forax [mailto:forax@univ-mlv.fr] Sent: Wednesday, March 8, 2017 2:23 AM To: Iris Clark <iris.clark(a)oracle.com> Cc: java-se-9-spec-experts(a)openjdk.java.net Subject: Re: Java SE 9 (JSR 379) Public Review Specification Hi Iris, in chapter 10: the module java.annotations.common has been renamed to java.xml.ws.annotation [1] cheers, Rémi [1] http://download.java.net/java/jdk9/docs/api/java.xml.ws.annotation-summary.…

1 0

Java SE 9 (JSR 379) Public Review Specification
by Iris Clark 07 Mar '17

07 Mar '17

Hi. The draft Public Review Specification is available here: http://cr.openjdk.java.net/~iris/se/9/java-se-9-pr-spec-01/java-se-9-spec.h… The main specification has changed slightly from the EDR, mostly notably with a reduction in the number of APIs proposed for removal in Section 10. Also we discovered that two JEPs (252 - Use CLDR Locale Data by Default; 280 - Indify String Concatenation) had an impact to the SE API, so they were added to the list of features in Sections 5 and 6. New to the draft are the following: - Annex 1, a detailed API specification-change summary - Annex 2, an annotated API specification showing the exact differences relative to Java SE 8 (JSR 337) - Annex 3, containing draft versions of The Java Language Specification (JLS) and the Java Virtual Machine Specification (JVMS) - Annex 4, an annotated version of the Java Native Interface Specification (JNI) showing differences relative to Java SE 8 I'd like to submit this to the JCP PMO for the formal Public Review period next week. Please let me know by 17:00 UTC next Tuesday, 14 March, if you believe changes are required, or you need additional time to for review. Thanks, iris

1 0

Welcome Volker Simonis to the JSR 379 EG
by Iris Clark 07 Mar '17

07 Mar '17

Hi. Please welcome Volker Simonis from SAP to the JSR 379 Expert Group. Volker has been an active member of the OpenJDK Community since the earliest days. He has worked on Java VMs in the SAP JVM Technology group for more than 10 years. He's the Project Lead for the OpenJDK PowerPC/AIX and s390x Port Projects and is a Reviewer in the JDK 8 and JDK 9 OpenJDK Projects. Finally, he represents SAP in the Java Community Process' Executive Committee. I'm looking forward to Volker's contributions to the Expert Group as we finish our work. Thanks, iris

2 1