On Thu, 12 Dec 2024 16:27:23 GMT, Christian Stein <[email protected]> wrote:
>>> `release of {0} too high: {1}`
>>
>> I think this is better. Probably good enough.
>>
>> My concern stems from the fact that 'release' doesn't seem to be defined for
>> _class files_. I see that the term 'release' exists, and maps to a versioned
>> directory, or you can compile classes _for_ a certain release, But, it seems
>> that 'the release of a class file' is a new concept here. (after all,
>> `javac` doesn't produce class files _with_ a certain release).
>>
>> Maybe: `class file {fp.entryName()} compiled for release
>> {fp.classReleaseVersion()}, is illegal in version directory {fp.mrversion()}`
>>
>> (This is perhaps somewhat terse, but `javac` sets the precedent for that. A
>> user could find out _why_ the version is illegal by referencing the jar file
>> spec).
>
> Let's try it out with the two examples from the initial description:
>
>
> release version of META-INF/versions/9/version/Version.class too high: 25
> release version of META-INF/versions/10/version/Version.class too high: 25
>
>
>
> class file META-INF/versions/9/version/Version.class compiled for release 25,
> is illegal in version directory 9
> class file META-INF/versions/10/version/Version.class compiled for release
> 25, is illegal in version directory 10
What about:
META-INF/versions/9/version/Version.class of class file major version 69 is
unsupported in versioned release 9; only supported in release >= 25
META-INF/versions/10/version/Version.class of class file major version 69 is
unsupported in versioned release 10; only supported in release >= 25
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22103#discussion_r1882967313