Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]
On Tue, 3 May 2022 01:20:10 GMT, Joe Darcy wrote:
>> 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
The negative definition above permits the property always to be undefined, but
we do want it to be defined when meaningful. It’s also getting to be an awful
lot of text to add to the otherwise terse tabular summary of system properties
in the [`System::getProperties()`
specification](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/System.html#getProperties()).
Consider using this text in the table:
> Java Runtime Environment specification maintenance version, which may be
> interpreted as a positive integer (optional, see below)
and then this in a paragraph following the table:
> The {@code java.specification.maintenance.version} property is defined if the
> specification implemented by this runtime at the time of its construction had
> undergone a https://jcp.org/en/procedures/jcp2#3.6.4;>maintenance
> release. When defined, its value identifies that maintenance release. To
> indicate the first maintenance release this property will have the value
> {@code "1"}; to indicate the second maintenance release this property will
> have the value {@code "2"}, and so on.
-
PR: https://git.openjdk.java.net/jdk/pull/8437
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]
On Mon, 2 May 2022 20:30:53 GMT, Joe Darcy 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:
>>
>>
>> * {@systemProperty
>> java.specification.maintenance.version}
>> * 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 > * href="https://jcp.org/en/procedures/jcp2#3.6.4;>specification
>> * maintenance release that required a change to the
>> runtime
>> * (optional).
>> *
>
> 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
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]
On Fri, 29 Apr 2022 17:11:55 GMT, Mark Reinhold wrote:
>> src/java.base/share/classes/java/lang/System.java line 743:
>>
>>> 741: * have the value {@code "1"}; after a second maintenance
>>> 742: * release, this property will have the value {@code "2"},
>>> 743: * and so on.
>>
>> There should be no requirement that values be allocated sequentially. In
>> other words, if JCP MR does not require an RI, then it should not be
>> surprising if there is no JDK build with maintenance version . As an
>> example, JSR 337 MR 1 and MR 2 both used the same RI. If this system
>> property had existed during development of MR 1, it would return "1". Since
>> no RI was submitted for MR 2, a build returning "2" should never exist. MR
>> 3 did update the RI, so it would return "3".
>
> @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:
>
>
> * {@systemProperty
> java.specification.maintenance.version}
> * 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 * href="https://jcp.org/en/procedures/jcp2#3.6.4;>specification
> * maintenance release that required a change to the
> runtime
> * (optional).
> *
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.
-
PR: https://git.openjdk.java.net/jdk/pull/8437
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]
On Fri, 29 Apr 2022 02:12:19 GMT, Iris Clark wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Change punctuation from review feedback.
>
> src/java.base/share/classes/java/lang/System.java line 743:
>
>> 741: * have the value {@code "1"}; after a second maintenance
>> 742: * release, this property will have the value {@code "2"},
>> 743: * and so on.
>
> There should be no requirement that values be allocated sequentially. In
> other words, if JCP MR does not require an RI, then it should not be
> surprising if there is no JDK build with maintenance version . As an
> example, JSR 337 MR 1 and MR 2 both used the same RI. If this system
> property had existed during development of MR 1, it would return "1". Since
> no RI was submitted for MR 2, a build returning "2" should never exist. MR 3
> did update the RI, so it would return "3".
@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:
* {@systemProperty
java.specification.maintenance.version}
* 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 https://jcp.org/en/procedures/jcp2#3.6.4;>specification
* maintenance release that required a change to the runtime
* (optional).
*
-
PR: https://git.openjdk.java.net/jdk/pull/8437
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]
On Fri, 29 Apr 2022 02:54:06 GMT, Joe Darcy wrote: > > Is there intent to backport this to the RI for JSR 337 MR 4? > > I think that would be helpful, if not strictly necessary. PS And if backported, the spec could be updated for earlier release trains to start at a different value like "4". - PR: https://git.openjdk.java.net/jdk/pull/8437
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]
On Fri, 29 Apr 2022 02:12:19 GMT, Iris Clark wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Change punctuation from review feedback.
>
> src/java.base/share/classes/java/lang/System.java line 743:
>
>> 741: * have the value {@code "1"}; after a second maintenance
>> 742: * release, this property will have the value {@code "2"},
>> 743: * and so on.
>
> There should be no requirement that values be allocated sequentially. In
> other words, if JCP MR does not require an RI, then it should not be
> surprising if there is no JDK build with maintenance version . As an
> example, JSR 337 MR 1 and MR 2 both used the same RI. If this system
> property had existed during development of MR 1, it would return "1". Since
> no RI was submitted for MR 2, a build returning "2" should never exist. MR 3
> did update the RI, so it would return "3".
> Is there intent to backport this to the RI for JSR 337 MR 4?
I think that would be helpful, if not strictly necessary.
-
PR: https://git.openjdk.java.net/jdk/pull/8437
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]
On Fri, 29 Apr 2022 02:00:08 GMT, Iris Clark wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Change punctuation from review feedback.
>
> src/java.base/share/classes/java/lang/VersionProps.java.template line 113:
>
>> 111: props.put("java.specification.version", VERSION_SPECIFICATION);
>> 112:
>> 113: // Uncomment next props.put call after the first maintenance
>> release for a
>
> Is "after" correct? I think this value should be set to the target MR at the
> beginning of RI development for the release, similar to what is done for
> other version identification system properties.
Well, sure -- this versioning info should be updated in the same way we update
versions for all the early access builds of a release.
-
PR: https://git.openjdk.java.net/jdk/pull/8437
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]
On Fri, 29 Apr 2022 01:20:17 GMT, Joe Darcy wrote:
>> Add a new system property, java.specification.maintenance.version, to return
>> the maintenance release number of the Java SE specification being
>> implemented. The property is unset, optional in the terminology of
>> System.getProperties, for an initial release of a specification.
>>
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
>>
>> I'll update copyright years before an integration.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Change punctuation from review feedback.
Is there intent to backport this to the RI for JSR 337 MR 4?
src/java.base/share/classes/java/lang/System.java line 743:
> 741: * have the value {@code "1"}; after a second maintenance
> 742: * release, this property will have the value {@code "2"},
> 743: * and so on.
There should be no requirement that values be allocated sequentially. In other
words, if JCP MR does not require an RI, then it should not be surprising
if there is no JDK build with maintenance version . As an example, JSR 337
MR 1 and MR 2 both used the same RI. If this system property had existed
during development of MR 1, it would return "1". Since no RI was submitted for
MR 2, a build returning "2" should never exist. MR 3 did update the RI, so it
would return "3".
src/java.base/share/classes/java/lang/VersionProps.java.template line 113:
> 111: props.put("java.specification.version", VERSION_SPECIFICATION);
> 112:
> 113: // Uncomment next props.put call after the first maintenance
> release for a
Is "after" correct? I think this value should be set to the target MR at the
beginning of RI development for the release, similar to what is done for other
version identification system properties.
-
Changes requested by iris (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/8437
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]
On Fri, 29 Apr 2022 01:20:17 GMT, Joe Darcy wrote: >> Add a new system property, java.specification.maintenance.version, to return >> the maintenance release number of the Java SE specification being >> implemented. The property is unset, optional in the terminology of >> System.getProperties, for an initial release of a specification. >> >> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764 >> >> I'll update copyright years before an integration. > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Change punctuation from review feedback. Thank you for the updates, Joe. Looks good to me. - Marked as reviewed by jpai (Committer). PR: https://git.openjdk.java.net/jdk/pull/8437
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]
> Add a new system property, java.specification.maintenance.version, to return > the maintenance release number of the Java SE specification being > implemented. The property is unset, optional in the terminology of > System.getProperties, for an initial release of a specification. > > Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764 > > I'll update copyright years before an integration. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Change punctuation from review feedback. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8437/files - new: https://git.openjdk.java.net/jdk/pull/8437/files/461407aa..2048aaac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8437=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8437=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8437.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8437/head:pull/8437 PR: https://git.openjdk.java.net/jdk/pull/8437
