Updated conformance text for Java SE 9

[mark.reinhold at oracle.com]

On a related note, here is some additional text to explain how
upgradeable modules can be used to replace selected APIs that,
in past releases, could be replaced via the Endorsed Standards
Override Mechanism.

Comments welcome.

- Mark

----

Upgradeable modules
-------------------

This Specification permits the user to replace certain APIs in an
Implementation of the Java SE Platform with newer versions, without
making any changes to that Implementation.

Two kinds of APIs are subject to replacement.  First, there are APIs in
the Java SE Platform that correspond to standards maintained outside of
the Java Community Process, such as CORBA.  Second, there are APIs in the
Java SE Platform that evolve with the Platform via the Java Community
Process, but which are intended to be usable on their own, i.e.,
_standalone_, on versions of the Platform other than the version where
they were developed.

Prior to Java SE 9, the [Endorsed Standards Override Mechanism][esom]
allowed the replacement of individual packages in APIs maintained outside
of the JCP, but allowed only a complete replacement of APIs evolved via
the JCP.  Java SE 9 takes advantage of the modular structure of the Java
SE Platform to allow the replacement of both kinds of APIs, and their
implementations, on a uniform module-by-module basis.  Specifically, Java
SE 9 categorizes each module in an Implementation as either _upgradeable_
or _non-upgradeable_, and allows an upgradeable module to be replaced by
the user without modifying or re-building the Implementation.  (The
Endorsed Standards Override Mechanism was deprecated in a Maintenance
Release of Java SE 8 and is not present in Java SE 9.)

An Implementation of the Java SE 9 Platform must provide a means to
replace those modules which are categorized as upgradeable, and must not
provide a means to replace those modules which are categorized as
non-upgradeable.  The rules for categorizing a module are as follows:

  - A Java SE module is upgradeable if, and only if, it defines an API
    that is subject to replacement.  Only a small number of Java SE
    modules fall into this category.  Examples are the `java.corba`
    module, which corresponds to a standard maintained outside of the
    Java Community Process, and the `java.transaction` and
    `java.xml.bind` modules, which are intended to be usable standalone.

  - A Java SE module is non-upgradeable if it is essential to the
    integrity of the Platform.  Most Java SE modules fall into this
    category, such as `java.base`, `java.xml`, and `java.management`.

  - A non-Java SE module is upgradeable unless the Implementation deems
    otherwise.

In order to replace an upgradeable module, the user provides an alternate
version which the Implementation observes in preference to the version
included in the Implementation.  The alternate version typically exports
APIs that are newer than those exported by the version in the
Implementation, although an Implementation is not required to check this.

(The Reference Implementation provides this capability via the
`--upgrade-module-path` command-line option.)

Java SE modules typically indicate in their specifications whether they
are upgradeable.  Non-Java SE modules generally need no such indication.

In Java SE 9, most of the Java SE modules which are upgradeable are
[deprecated for removal][#s10].


[s10]: XXX #s10 (http://cr.openjdk.java.net/~iris/se/9/java-se-9-pr-spec/#s10)
[esom]: http://docs.oracle.com/javase/8/docs/technotes/guides/extensions/index.html