Updated conformance text for Java SE 9

[mark.reinhold at oracle.com]

2017/7/26 11:22:31 -0700, volker.simonis at gmail.com:
> On Tue, Jul 25, 2017 at 9:09 PM, mark.reinhold at oracle.com wrote:
>> 2017/7/25 10:17:06 -0700, volker.simonis at gmail.com:
>>> ...
>>> 
>>> And finally a new point which I only became aware of recently. What's
>>> the relation of upgradeable and automatic module? I.e. can a plain old
>>> jar file be used to upgrade a module? In the current RI it can and I
>>> think that this is crucial because the whole mechanism is actually
>>> designed for APIs which are usable on their own or that correspond to
>>> standards maintained outside of the JCP. The only requirement for this
>>> to work is that the jar file is either named in such a way that its
>>> automatically created module name matches with that of the module or
>>> that the jar file explicitly uses a corresponding
>>> Automatic-Module-Name attribute in its manifest. So maybe you could
>>> add a sentence like "a module can also be upgraded by a plain old jar
>>> file if the automatic module name of the jar file is the same like the
>>> name of the module"?
>> 
>> Sure.  To the existing paragraph:
>> 
>>  In order to replace an upgradeable module, the user supplies 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 enforce this property.
>> 
>> I will append:
>> 
>>  The alternate version may be provided in the form of a JAR file that
>>  defines an automatic module.
> 
> That's good although I'd maybe add something like "..an automatic
> module with the same name like the upgradeable module".
> 
> Just saw several people recently wondering why placing .jar files with
> upgraded API's (e.g. jta.jar for the transaction API) into the
> --upgrade-module-path didn't work. So getting the automatic module to
> match the upgradeable modules name is the tricky part here.

The "same name" requirement applies whether or not the alternate version
is an automatic module, so I'll call that out earlier in the paragraph:

  In order to replace an upgradeable module, the user supplies an
  alternate version which the Implementation observes in preference to
  the version included in the Implementation.  The alternate version
  must have the same module name.  It will typically export APIs that
  are newer than those exported by the version in the Implementation,
  although an Implementation is not required to enforce this property.
  The alternate version may be provided in the form of a JAR file that
  defines an automatic module.

Thanks for all your suggestions!

- Mark