RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]
Iris Clark
iris at openjdk.java.net
Fri Apr 29 02:19:41 UTC 2022
On Fri, 29 Apr 2022 01:20:17 GMT, Joe Darcy <darcy at openjdk.org> 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 <x> does not require an RI, then it should not be surprising if there is no JDK build with maintenance version <x>. 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
More information about the core-libs-dev
mailing list