August 2017 - java-se-9-spec-observers

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