Question regarding the "Modular platform"

[mark.reinhold at oracle.com]

2017/4/26 13:51:51 -0700, mark.reinhold at oracle.com:
> 2017/3/9 3:56:12 -0800, Simon Ritter <sritter at azul.com>:
>> thanks for the answers you've provided.  I have some follow-on and 
>> related questions.
> 
> Thanks for your questions.
> 
> Our intent is to allow custom run-time images generated by the `jlink`
> tool to be redistributed in the same way that a full Java SE JRE can
> be redistributed, without any need for further conformance testing.

Attached below is revised text for the "Conformance" subsection of the
"Modular platform" section of the specification.

If you still have questions, please let me know.

- Mark

----

Every Implementation of this Specification must include the `java.base`
module.  An Implementation may, further, include one or more additional
standard SE modules so long as the set of SE modules is closed, i.e.,
contains every SE module required, via `requires transitive` directives,
by any member of the set.  Such an Implementation is considered to fully
implement this Specification even if it does not include all of the SE
modules.  The Technology Compatibility Kit (TCK) for this Specification
will be able to test all of the SE modules present in a Platform
Implementation, and it will require that set to be 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.

If an Implementation of this Specification includes an SE module then it
must fully implement the corresponding part of this Specification.  It
must implement every API element of that module including the module’s
name, its exported API packages, and any `requires transitive`
dependences.  It must not export any of that module's other API packages
without qualification.

An Implementation of this Specification may be accompanied by a set of
implementation-specific module artifacts that correspond to the modules,
standard or otherwise, that are present in that Implementation, along
with an implementation-specific linking tool that can combine those
artifacts to create further Implementations that satisfy the constraints
of the previous two paragraphs but might not contain all of the modules
present in the original Implementation.  The Reference Implementation
(RI) will have this structure.