Updated conformance text for Java SE 9

[mark.reinhold at oracle.com]

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.