On Mon, 2 May 2022 20:30:53 GMT, Joe Darcy <da...@openjdk.org> 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