On Mon, 5 Jun 2023 06:05:14 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> Joe Darcy has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains two additional commits
>> since the last revision:
>>
>> - Merge branch 'master' into JDK-8295071
>> - JDK-8309415: Spec Clarification : ClassFileFormatVersion: System property
>> java.class.version | Java class format version number
>
> src/java.base/share/classes/java/lang/System.java line 758:
>
>> 756: * <td>Greatest Java class file format version recognized by
>> the runtime as {@code "MAJOR.MINOR"}
>> 757: * where {@link
>> java.lang.reflect.ClassFileFormatVersion#major() MAJOR} and {@code MINOR}
>> 758: * are both formatted as decimal integers</td></tr>
>
> I'm not sure about using the adjective "Greatest" here, only because
> "Greatest ... recognized" reads a bit like recognition of greatness when it
> really wants to convey that it's the highest version recognized.
>
> Does the wording need to take account of running with preview features
> enabled?
>
> The table uses "Java runtime" rather than "runtime" in the description of
> some of the other properties.
>
> In passing, should the descriptions of RELEASE_xxx in ClassFileFormatVersion
> say "The highest version recognized" rather than the "The version recognized"?
Update PR and CSR to use the wording:
"Latest Java class file format version recognized by the Java runtime as
"MAJOR.MINOR" where MAJOR and MINOR are both formatted as decimal integers"
While it wouldn't be unreasonable to assume that when running under
--enable-preview that the minor version was 65535, it is printed out as 0 with
or without preview being enabled.
I didn't want to broach preview-ness as part of this update to either promise
or document the current behavior.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14305#discussion_r1218416628
