- java-se-9-spec-observers

Java SE 9 (JSR 379) Final Release
by Iris Clark 25 Sep '17

25 Sep '17

Hi. The JCP EC approved the Final Release Specification on 11 September. The Final Release version of the JSR 379 Specification, with instructions on how to find the RI and the TCK, is here: https://jcp.org/aboutJava/communityprocess/final/jsr379/index.html Thank you for your participation. This EG is now disbanded. Our three mailing lists remain online for archival purposes, but no longer accept messages. Iris

1 0

java SE 9 (JSR 379) Final Release Specification, RI, and TCK DRAFT
by Iris Clark 15 Aug '17

15 Aug '17

The draft Final Release Specification is available here: http://cr.openjdk.java.net/~iris/se/9/java-se-9-fr-spec-01/ This draft includes the following minor changes: - Annex 2, 5: Updated to the recent JDK 9 build 181 promotion. - Annex 3: Introductory text updated. The draft Reference Implementation, based on JDK 9 build 181, will be available here shortly: http://jdk.java.net/java-se-ri/9 The official RI is under the GPL license. Equivalent builds will also be provided at a later date under the Oracle Binary Code License for those who prefer that. The draft TCK has already been made available to EG members. The most recent promotion is build 66, based on JDK 9 build 176. The final TCK, build 68, based on JDK 9 build 181 is expected later this week. There are no significant changes between the two builds. I plan to submit this to the JCP PMO for the Final Approval Ballot next week. Please let me know by 23:59 UTC next Monday, 21 August, if you think any changes are required. Thanks, Iris

2 2

Updated conformance text for Java SE 9
by mark.reinhold＠oracle.com 08 Aug '17

08 Aug '17

Attached below is revised and expanded text for the "Conformance" subsection of the "Modular platform" section [1] of the specification. This version clarifies some details in the previous version [2] and, further, specifies the manner in which the strong encapsulation of modules may be relaxed. Comments welcome. - Mark [1] http://cr.openjdk.java.net/~iris/se/9/java-se-9-pr-spec/#s7 [2] http://mail.openjdk.java.net/pipermail/java-se-9-spec-experts/2017-May/0000… ---- Every Implementation of this Specification must include the `java.base` module, _i.e._, must make that module observable. An Implementation may, further, include one or more additional Java SE modules so long as the set of Java SE modules that the Implementation includes is _closed_, i.e., contains every Java SE module required, via `requires transitive` directives, by any member of the set. For a specific example, an Implementation that contains just the `java.base`, `java.sql`, `java.logging`, and `java.xml` modules is closed because the only `requires transitive` dependences are from `java.sql` to `java.logging` and `java.xml`, and the latter two modules are members of the set. The Technology Compatibility Kit (TCK) for this Specification will be able to test all of the Java SE modules included in an Implementation, and it will require that set to be closed. An Implementation that passes the TCK is considered to fully implement this Specification even if it does not include all of the Java SE modules. If an Implementation of this Specification includes a Java SE module then it must fully implement the corresponding part of this Specification. It must, in particular, implement every API element of that module including the module’s name, its exported packages, and any `requires transitive` dependences. It must not export any of that module’s other packages without qualification. This Specification defines the Licensor Name Space on a module-by-module basis. Provided that an Implementation that fully implements this Specification includes the required Licensor Name Space for each included module then it is not considered to subset the Licensor Name Space. An Implementation of this Specification may provide a means to create further Implementations. If it does so then any new Implementation must satisfy the constraints of the preceding paragraphs but need not include all of the modules present in the original Implementation. As an aid to migration, an Implementation may relax the strong encapsulation of the modules that it includes as follows: - An Implementation may provide a means to invoke its run-time system with one or more packages of one or more of its modules open to code in all unnamed modules, i.e., to code on the class path. The first access to an element of such a package by a program via a reflection API must cause a warning to be issued on the standard error stream. Later accesses may also cause warnings to be issued. - An Implementation may, by default, open one or more packages of one or more of its modules to code in all unnamed modules. If it does so then it must issue warnings as described in the previous paragraph. If it does so then it must, further, provide a means to invoke its run-time system without opening any packages of any of its modules. (The Reference Implementation's run-time system behaves this way by default, and because this is the default it can also be invoked without opening any of its packages via the command-line option `--illegal-access=deny`.) - An Implementation may provide a means to request that additional warnings or debugging information, such as stack traces, be issued when elements of its open packages are accessed via a reflection API. (The Reference Implementation's run-time system can be invoked with the command-line options `--illegal-access=warn` or `--illegal-access=debug` in order to request warnings or both warnings and stack traces, respectively, on each unique reflective access to any open Implementation package.) Future revisions of this Specification are expected to mandate that all of an Implementation's modules be strongly encapsulated by default and, eventually, to disallow the above-described relaxation. As a further aid to migration, an Implementation may provide a means to invoke its run-time system in a way that establishes additional relationships between specific modules, identified by name, regardless of the original declarations of those modules and regardless of whether those modules are included in the Implementation or are part of the application being run: - One module can be made to read another module. (The Reference Implementation provides this capability via the `--add-reads` command-line option.) - A package of one module can be opened to another module. (The Reference Implementation provides this capability via the `--add-opens` command-line option.) - A package of one module can be exported to another module. (The Reference Implementation provides this capability via the `--add-exports` command-line option.) - A package of one module can be opened or exported to every unnamed module. (The Reference Implementation provides this capability by allowing the special token `ALL-UNNAMED` to be used as a target of the `--add-opens` and `--add-exports` command-line options.) None of these capabilities, for any modules, may be operative by default. A future revision of this Specification may disallow these capabilities.

5 18

Re: Evaluating the TCK for JSR 376
by mark.reinhold＠oracle.com 08 Aug '17

08 Aug '17

2017/7/28 9:33:30 -0700, tim_ellison(a)uk.ibm.com: > "Volker Simonis" <volker.simonis(a)gmail.com> wrote on 27/07/2017 10:50:38: >> ... >> >> That's a nice feature for playing around, but I think the TCK >> conformance test should by default really use and test all the default >> platform modules from the runtime image under test and automatically >> tests all these modules (i.e. it should check all exports, all the >> requires transitive relations and finally it should check if the >> modules form a "closed" subset with regard to the specification (i.e. >> 'requires transitive') and also a "closed" subset with regard to the >> implementation (i.e. 'requires')). >> >> I think this will make it possible for malicious people to certify >> custom images which don't conform to the specification (because as far >> as I see the TCK doesn't test a complete implementation but just the >> part you ask it to test). But you probably already know that. > > I think that is a usability request rather than a requirement on the TCK. > > While it would be desirable for the TCK to check that the Implementation > adheres to *all* the obligations of the Specification, that is unlikely > to be achievable. > > The TCK can't stop "malicious people" claiming compliance where they don't > follow the conditions of the Specification, or run the TCK as intended, > including testing all the SE modules in the Implementation. > > However, I agree it is a desirable enhancement and will reduce honest > mistakes. Agreed. - Mark

1 0

Java SE 9 PFD Specification posted to jcp.org
by Iris Clark 02 Aug '17

02 Aug '17

FYI: https://jcp.org/en/jsr/detail?id=379 Thanks, Iris

1 0

Re: Evaluating the TCK for JSR 376
by Tim Ellison 28 Jul '17

28 Jul '17

"Volker Simonis" <volker.simonis(a)gmail.com> wrote on 27/07/2017 10:50:38: > I have access to the TCK and I did some basic tests with it. The main > problem (which I've already addressed in February but which I was told > won't be fixed for 9) is the following: > > The current TCK (i.e. the ModuleGraphTest) only tests the requirements > for specific modules (i.e. tests if all the modules given on the > command line or selected in the harness, have the required export and > requires edges). There are also tests which check the "closure" of a > set of modules (with regard to the 'requires' and 'requires > transitive' relation) but again only for the specific set given on the > command line or choose in the harness. > > That's a nice feature for playing around, but I think the TCK > conformance test should by default really use and test all the default > platform modules from the runtime image under test and automatically > tests all these modules (i.e. it should check all exports, all the > requires transitive relations and finally it should check if the > modules form a "closed" subset with regard to the specification (i.e. > 'requires transitive') and also a "closed" subset with regard to the > implementation (i.e. 'requires')). > > I think this will make it possible for malicious people to certify > custom images which don't conform to the specification (because as far > as I see the TCK doesn't test a complete implementation but just the > part you ask it to test). But you probably already know that. I think that is a usability request rather than a requirement on the TCK. While it would be desirable for the TCK to check that the Implementation adheres to *all* the obligations of the Specification, that is unlikely to be achievable. The TCK can't stop "malicious people" claiming compliance where they don't follow the conditions of the Specification, or run the TCK as intended, including testing all the SE modules in the Implementation. However, I agree it is a desirable enhancement and will reduce honest mistakes. Regards, Tim > On Tue, Jul 25, 2017 at 9:54 PM, <mark.reinhold(a)oracle.com> wrote: > > If any member of this EG would like to evaluate the TCK for this JSR > > (i.e., the JCK), and if you do not already have access to it, please > > let me know and I'll make the necessary arrangements. > > > > - Mark > 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

1 0

Java SE 9 (JSR 379) Proposed Final Draft: DRAFT 3
by Iris Clark 27 Jul '17

27 Jul '17

The third draft of the Proposed Final Draft (PFD) Specification is available here: http://cr.openjdk.java.net/~iris/se/9/java-se-9-pfd-spec-03/ This draft includes the following minor changes: - Spec, Section 7: Additional modifications based on comments from Volker Simonis to upgradeable modules - Annex 2, 5: Update to recent build 180 promotion As before, the deadline for comments before I submit this to the JCP PMO as the formal Proposed Final Draft is unchanged. Please let me know by 23:59 UTC next Monday, 31 July, if you think any changes are required. Thanks, Iris

1 0

Java SE 9 (JSR 379) Proposed Final Draft: DRAFT 2
by Iris Clark 26 Jul '17

26 Jul '17

The second draft of the Proposed Final Draft (PFD) Specification is available here: http://cr.openjdk.java.net/~iris/se/9/java-se-9-pfd-spec-02/ This draft includes the following minor changes: - Spec, Section 7: Modifications based on comments from Volker Simonis to Upgradeable modules and illegal-access warnings - Annex 1, 3, 4: Fix links The deadline for comments before I submit this to the JCP PMO as the formal Proposed Final Draft is unchanged. Please let me know by 23:59 UTC next Monday, 31 July, if you think any changes are required. Thanks, Iris

1 0

Re: Updated conformance text for Java SE 9 (JSR 379)
by mark.reinhold＠oracle.com 25 Jul '17

25 Jul '17

// Replying to both EG lists, for the record. 2017/7/25 11:15:57 -0700, volker.simonis(a)gmail.com: > On Tue, Jul 11, 2017 at 7:10 PM, <mark.reinhold(a)oracle.com> wrote: >> Attached below is revised and expanded text for the "Conformance" >> subsection of the "Modular platform" section [1] of the Java SE 9 >> (JSR 379) specification. ... >> >> ---- >> >> ... >> >> As an aid to migration, an Implementation may relax the strong >> encapsulation of the modules that it includes as follows: >> >> - An Implementation may provide a means to invoke its run-time system >> with one or more packages of one or more of its modules open to code >> in all unnamed modules, i.e., to code on the class path. The first >> access to an element of such a package by a program via a reflection >> API must cause a warning to be issued on the standard error stream. >> Later accesses may also cause warnings to be issued. >> >> - An Implementation may, by default, open one or more packages of one >> or more of its modules to code in all unnamed modules. If it does so >> then it must issue warnings as described in the previous paragraph. >> If it does so then it must, further, provide a means to invoke its >> run-time system without opening any packages of any of its modules. >> >> (The Reference Implementation's run-time system behaves this way by >> default, and because this is the default it can also be invoked >> without opening any of its packages via the command-line option >> `--illegal-access=deny`.) > > This is still not totally clear to me. Does it mean the specification > requires at least one warning for each package where we have an > illegal access, for each module where we have an illegal access or is > one single warning per invocation of the VM enough? One single warning per invocation of the VM. You're right -- this could be more clear. How about: - An Implementation may provide a means to invoke its run-time system with one or more packages of one or more of its modules open to code in all unnamed modules, i.e., to code on the class path. If the run-time system is invoked in this way, and if by doing so some invocations of the reflection APIs succeed where otherwise they would have failed, then the first such invocation must cause a warning to be issued on the standard error stream. Later such invocations may also cause warnings to be issued. Is that better? - Mark

2 1

Java SE 9 (JSR 379) Proposed Final Draft
by Iris Clark 25 Jul '17

25 Jul '17

The draft of the Proposed Final Draft (PFD) Specification is available here: http://cr.openjdk.java.net/~iris/se/9/java-se-9-pdf-spec-01/ The biggest changes since PR are in Section 7, "Modules", which contains the recently-discussed text for conformance and upgradeable modules, and the addition of Annex 5 containing the complete Java SE 9 API Specification. This draft includes the following changes: - Spec, Section 4: Add references to specific Maintenance Releases to JSRs 222, 224, and 925. - Spec, Section 7: New text per discussion, including subsections for constraints, relaxing strong encapsulation, overriding module declarations, and upgradeable modules. This draft includes some of the suggestions that Tim sent earlier today; there may be additional minor changes after further discussion. - Spec, Section 9: Add subsection for removal of LambdaMetafactory default constructor. - Spec, Section 10: Add "java.se.ee" aggregator module to list of modules proposed for removal. - Annex 1, 3: Updates based on development since PR. - Annex 2: Diffs against recent build 179 promotion. - Annex 5: New - Java SE 9 API Specification. I plan to submit this to the JCP PMO as the formal Proposed Final Draft next week. Please let me know by 23:59 UTC next Monday, 31 July, if you think any changes are required. Thanks, Iris

1 0