From iris.clark at oracle.com Tue Mar 7 06:40:51 2017 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 6 Mar 2017 22:40:51 -0800 (PST) Subject: Welcome Volker Simonis to the JSR 379 EG Message-ID: <06312ebc-1d75-4f31-81db-44e7de660899@default> 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 From Tim_Ellison at uk.ibm.com Tue Mar 7 10:08:24 2017 From: Tim_Ellison at uk.ibm.com (Tim Ellison) Date: Tue, 7 Mar 2017 10:08:24 +0000 Subject: Welcome Volker Simonis to the JSR 379 EG In-Reply-To: <06312ebc-1d75-4f31-81db-44e7de660899@default> References: <06312ebc-1d75-4f31-81db-44e7de660899@default> Message-ID: Welcome Volker! > From: Iris Clark > 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 > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From iris.clark at oracle.com Tue Mar 7 18:19:30 2017 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 7 Mar 2017 10:19:30 -0800 (PST) Subject: Java SE 9 (JSR 379) Public Review Specification Message-ID: <5ff031fd-d2d9-4f3b-94a7-3a7763d4eb8d@default> 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.html 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 From iris.clark at oracle.com Wed Mar 8 22:24:14 2017 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 8 Mar 2017 14:24:14 -0800 (PST) Subject: Java SE 9 (JSR 379) Public Review Specification In-Reply-To: <554728828.1216850.1488968590348.JavaMail.zimbra@u-pem.fr> References: <5ff031fd-d2d9-4f3b-94a7-3a7763d4eb8d@default> <554728828.1216850.1488968590348.JavaMail.zimbra@u-pem.fr> Message-ID: 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 at univ-mlv.fr] Sent: Wednesday, March 8, 2017 2:23 AM To: Iris Clark Cc: java-se-9-spec-experts at 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.html From mark.reinhold at oracle.com Thu Mar 9 00:49:27 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 8 Mar 2017 16:49:27 -0800 (PST) Subject: Question regarding the "Modular platform" In-Reply-To: References: Message-ID: <20170309004927.9485481637@eggemoggin.niobe.net> 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 at 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 From sritter at azul.com Thu Mar 9 11:56:12 2017 From: sritter at azul.com (Simon Ritter) Date: Thu, 9 Mar 2017 04:56:12 -0700 Subject: Question regarding the "Modular platform" In-Reply-To: <20170309004927.9485481637@eggemoggin.niobe.net> References: <20170309004927.9485481637@eggemoggin.niobe.net> Message-ID: Mark, thanks for the answers you've provided. I have some follow-on and related questions. In Java SE 8 and in all prior Java SE releases, there is a clear "all or nothing" treatment of what a spec-compliant implementation is: a compliant implementation is an implementation that has passed the TCKs. Taking such a compliant implementation and distributing only a portion of it (e.g. "choosing only the classes you need") is clearly distributing something that is not a compliant implementation, and is not entitled to the same IP rights that compliant implementations do (i.e. is not eligible for the same guaranteed patent licenses provided by the JSPA). Java SE 9, through modules and the jlink capability, creates a new (potentially commonly used) mechanism for taking a compliant implementation and repackaging some arbitrary subset of that implementation's materials for redistribution. This raises various IP-rights related questions: 1. Is distribution of the output from jlink packaging for a specific application considered distribution of a spec-compliant implementation? 2. Does such a distribution carry IP rights (including patent right) that a compliant implementation does via the JSPA? 3. If the answer to the previous question is yes, how does one demonstrate that a distribution of a jlink output is compliant with the spec? 3.1 How do you run the TCK on this jlink output? 3.2 Who has the rights to run the TCK on such jlink output? 3.3. If no TCK is run on the jlink output, is it compliant? A possible interpretation of the JSPA IP flow rules is this: under the TCK mechanisms that we've seen in the past (we have not yet seen what TCKs for Java SE 9 will look like, so maybe something is addressing it that we don't yet know about), the answers to the above would be straightforward: jlink output created by someone who does not have a TCK license cannot be tested with the TCK, cannot therefore (by definition) be determined to be a compliant implementation of the spec., and does not (by definition) inherit the IP rights that the compliant distribution it was built from carried. Assuming this straightforward possible interpretation is correct, it would mean that jlink output artifacts are not practically redistributable (or even practically useable) without significant IP exposure risk. Using such an artifact would (almost by definition) entail making use of known necessary patents without a license allowing that use. This would rather seem to defeat the purpose of jlink. Regards, Simon. On 08/03/2017 17:49, mark.reinhold at oracle.com wrote: > 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 at 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 From iris.clark at oracle.com Fri Mar 10 18:42:39 2017 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 10 Mar 2017 10:42:39 -0800 (PST) Subject: Java SE 9 (JSR 379) Public Review Specification (DRAFT 2) Message-ID: 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.html 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 From iris.clark at oracle.com Tue Mar 21 15:18:17 2017 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 21 Mar 2017 08:18:17 -0700 (PDT) Subject: Java SE 9 PR Specification posted to jcp.org Message-ID: <2f1e6184-54c1-4bf7-b011-bb268be4638f@default> FYI: https://jcp.org/en/jsr/detail?id=379 The review period ends Thu 20 Apr. Thanks, Iris From volker.simonis at sap.com Tue Mar 28 13:09:07 2017 From: volker.simonis at sap.com (Simonis, Volker) Date: Tue, 28 Mar 2017 13:09:07 +0000 Subject: Mandatary nature of standard Java SE modules Message-ID: <15c3cc98b4794717851bcd22abb3f341@DEROTE13DE07.global.corp.sap> 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. From volker.simonis at sap.com Tue Mar 28 13:29:11 2017 From: volker.simonis at sap.com (Simonis, Volker) Date: Tue, 28 Mar 2017 13:29:11 +0000 Subject: Custom configurations and definition of "closed set" Message-ID: 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.html