On Mon, 2 May 2022 20:30:53 GMT, Joe Darcy <[email protected]> wrote:
>> @irisclark does raise an interesting point: If, say, MR 2 doesn’t require a
>> change to the RI then the MR 1 RI is also the MR 2 RI, but its
>> `java.specification.maintenance.version` property will report that it’s the
>> MR 1 RI.
>>
>> One way to fix this would be to require an RI update with every MR just to
>> update this property, even if no other code in the RI changes — but we
>> prefer to avoid doing RI builds unnecessarily.
>>
>> Another way to fix it would be to finesse the specification of this
>> property, perhaps:
>>
>>
>> * <tr><th scope="row">{@systemProperty
>> java.specification.maintenance.version}</th>
>> * <td>Java Runtime Environment specification maintenance version,
>> which may
>> * be interpreted as a non-zero integer. If defined, the value
>> of this
>> * property is the identifying number of the most recent <a
>> * href="https://jcp.org/en/procedures/jcp2#3.6.4";>specification
>> * maintenance release</a> that required a change to the
>> runtime</a>
>> * <em>(optional)</em>.
>> * </td></tr>
>
> In the latest push, to address the concerns raised updated the proposed
> wording to, in plain text:
>
> Java Runtime Environment specification maintenance version, not defined
> before the specification implemented by this runtime has undergone a
> maintenance release (optional). When defined, the value of this property may
> be interpreted as a positive integer. The value indicates the latest
> maintenance release the runtime is known to support. A later release may be
> supported by the environment. To indicate the first maintenance release this
> property will have the value "1"; to indicate the second maintenance release,
> this property will have the value "2", and so on.
PS CSR Updated to reflect this push; please review:
https://bugs.openjdk.java.net/browse/JDK-8285764
-------------
PR: https://git.openjdk.java.net/jdk/pull/8437
