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

Reply via email to