On Thu, 12 Dec 2024 15:23:43 GMT, Christian Stein <cst...@openjdk.org> wrote:
>> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 94:
>>
>>> 92: unexpected versioned entry {0} for release {1}
>>> 93: error.release.value.toohigh.versioned.entry=\
>>> 94: classfile release value of {0} too high: {1}
>>
>> Not sure about the term 'release value' here. Is that defined somewhere?
>>
>> Maybe leaning on 'class file major version' like this would work better?
>>
>> Suggestion:
>>
>> error.release.value.toohigh.versioned.entry=\
>> class file {0} targeting version '{1}' must have a major version
>> lower or equal to '{2}' , but was '{3}'
>>
>>
>> And then `{0}` is the entry, `{1}` is the `mrversion`, `{2}` is the class
>> file major version associated with that `mrversion`, and `{3}` was the
>> actual class file major version.
>>
>> (also, 'class file' is two words)
>
> In this context the actual class file major version doesn't add any value to
> communicate the issue to the user:
> - `javac --release N` and
> - `jar --release N` use the "Java release feature number" in their options,
> so does the
> - `META-INF/versions/N` path.
User-facing help messages read:
javac --help
...
--release <release>
Compile for the specified Java SE release.
Supported releases:
8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25
jar --help
...
--release VERSION Places all following files in a versioned directory
of the jar (i.e. META-INF/versions/VERSION/)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22103#discussion_r1882372640
