[
https://issues.apache.org/jira/browse/MJAR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693678#comment-17693678
]
Jorge Solórzano commented on MJAR-62:
-------------------------------------
This issue as it stands out today is irrelevant, and it actually does the
correct thing, let me explain:
The {{MANIFEST.MF}} does not reflect the version of the compiler that built the
jar because you can compile a class using a higher JDK version that targets a
lower Java bytecode, so assume that you build a JAR that compiles the classes
with JDK 17 but targets (–release) Java 11, which version do you use as
*Build-Jdk* option? you are using Java 17 so it makes sense to set the version
to {+}17{+}, but at the same time, you are compiling to Java 11 so you could
argue that it must use {+}11{+}, but that is not true, and even the bytecode
produced could be different.
But even if we try to use the "same" version in the *Build-Jdk* property that
compiles the classes, the most important point that this is irrelevant now, is
that we now have Multi-Release JARs ("MRJAR"), that contain bytecode generated
for different Java versions in a versioned area of the JAR, so, if you build a
JAR which compiles the base classes as Java 8, and have versioned classes for
Java 9, Java 11, and Java 17, which version do you set in the *Build-Jdk*
property? If you use the lower one (Java 8) that is not correct since it
contains classes with different bytecode, and if you use the higher one (Java
17) that could not be entirely true as you might probably build the JAR using
JDK 19.
In the end, the *Build-Jdk* should be used more as a property to signal which
JDK was used to build (or a better term "assemble") the JAR rather than to know
the compiled bytecode contained, when I mean that it actually does the correct
thing is because if the JDK used to assemble the JAR is the one that Maven
uses, then that's the JDK to be used in the property.
NOTE: This has no relation with the issue MJAR-289 since Toolchains handling is
a different topic and this issue does not duplicate that, and while I agree
that toolchain support could be improved, the same premise should be done, if
maven-jar-plugin is aware of the toolchain, and the toolchain of
maven-compiler-plugin is different from the toolchain used in maven-jar-plugin,
which version should be used in the property? of course the one that uses
maven-jar-plugin, yet doesn't need any special treatment since it will use the
"java.version" property which again is the correct thing to do.
> Build-Jdk in Manifest.mf does not reflect which compiler version actually
> compiled the classes in the jar
> ---------------------------------------------------------------------------------------------------------
>
> Key: MJAR-62
> URL: https://issues.apache.org/jira/browse/MJAR-62
> Project: Maven JAR Plugin
> Issue Type: Bug
> Reporter: Stefan Magnus Landrø
> Priority: Major
> Attachments: example-app.zip
>
>
> Manifest.mf does not reflect the version of the compiler that built the jar,
> but defaults to the version that maven runs under: Build-Jdk:
> ${java.version}.
> I believe this makes users uncertain of which compiler was actually used to
> build the classes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
