On Fri, 29 Apr 2022 01:20:17 GMT, Joe Darcy <da...@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
