On Thu, 14 Nov 2024 11:57:52 GMT, Christian Stein <cst...@openjdk.org> wrote:
> Please review this change ensuring all targeted classes in a MR-JAR file
> should target the same or a lower classfile version.
>
> For example, having compiled source files with `javac` 25 without using the
> `--release` option (or with `--release 25`) and trying to archive them via a
> `jar --create --file a.jar --release 9 ... --release 10 ...` command now
> fails with:
>
> classfile release value of META-INF/versions/9/version/Version.class too
> high: 25
> classfile release value of META-INF/versions/10/version/Version.class too
> high: 25
> invalid multi-release jar file a.jar deleted
>
>
> This pull request contains fixes to existing tests which produced invalid
> MR-JAR files. Most of those fixes are achieved by adding an appropriate
> `--release N` option to the associated `javac` call. One of those fixes
> rewrites the classfile version bytes between the `javac` and `jar` calls.
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)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22103#discussion_r1882289038
