Updated conformance text for Java SE 9

[Simon Ritter]

Mark,
thanks for the revised and expanded text.  I think this clarifies things 
clearly in respect of how a runtime generated using jlink (or a similar 
tool) conforms to the specification.

There's a still a few things that I'd like to clarify further.

"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." Presumably, it is not 
necessary to run the TCK on all possible combinations of modules to 
determine which are closed (and therefore in conformance) and which are 
not.

How do we verify that the output from a jlink-like command is in 
conformance?  Is there some test or tests that can be run on jlink (or 
similar) to guarantee that it can only produce conformant runtime 
distributions?  Alternatively, will there be some test tool that can be 
used on the output of jlink to verify that the Java SE modules included 
are closed?

"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."  The way I interpret this, it means that any jlink 
produced runtime that includes a closed set of Java SE modules, each of 
which conforms to the Licensor Name Space, will be deemed to be a 
conformant implementation of the Java SE 9 specification. Any user of 
such a Java runtime will, therefore, be granted the IP rights as defined 
by the JSPA (Section 5.B).  Is that correct?

Thanks,

Simon.

On 11/07/2017 18:09, mark.reinhold at oracle.com wrote:
> 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/000020.html
>
> ----
>
> 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.