Updated conformance text for Java SE 9
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Wed Jul 26 20:14:46 UTC 2017
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!
More information about the java-se-9-spec-observers