[
https://issues.apache.org/jira/browse/PROTON-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099823#comment-17099823
]
ASF subversion and git services commented on PROTON-2206:
---------------------------------------------------------
Commit 582dcac3231aff30021664a1f194e669f693b99a in qpid-proton-j's branch
refs/heads/master from Robbie Gemmell
[ https://gitbox.apache.org/repos/asf?p=qpid-proton-j.git;h=582dcac ]
PROTON-2206: add maven.compiler.release config when building with JDK9+
> add maven.compiler.release configuration on JDK9+
> -------------------------------------------------
>
> Key: PROTON-2206
> URL: https://issues.apache.org/jira/browse/PROTON-2206
> Project: Qpid Proton
> Issue Type: Task
> Components: proton-j
> Reporter: Robbie Gemmell
> Assignee: Robbie Gemmell
> Priority: Minor
> Fix For: proton-j-0.34.0
>
>
> Currently we set the maven.compiler.source and maven.compiler.target option
> properties (the apache parent pom 'defaults' them to 1.6, we override and
> bump to 1.8). As is known, though these control the source level and target
> bytecode version during compilation, the compilation occurs with the API
> signatures of the active JDK, and if they have changed in source-compatible
> ways in the newer JDK can still result in compiling bytecode that isnt
> runtime-compatible with the older JVM being targetted (unless the
> 'bootclasspath' is also used when compiling to supply the target signatures,
> which it often isnt, or the source is actually updated to take the issue into
> consideration and make specific attempts to avoid the problems occurring).
> http://openjdk.java.net/jeps/247 added a -release flag to javac from Java 9
> to use instead of the other options and actually result in use of the API
> signatures from the specified Java version while compiling with the newer JDK
> to avoid the issue. We should add the related maven.compiler.release property
> config when running on JDK 9+ to use this support, thus avoiding issues when
> mixing JVM versions. We perform releases using JDK8 so this isnt a problem in
> that regard, but it does occasionally come up during ongoing
> development/testing and can be a pain in that regard.
> This new release flag is said to use the same "one + three back" policy
> previously used for -source and -target from http://openjdk.java.net/jeps/182
> (based on dropping release=6 in JDK 12,
> https://bugs.openjdk.java.net/browse/JDK-8028563 / thread
> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001190.html). Since
> the JDK later moved to 6 month releases and per that thread, this policy
> seems to now mean 1 + 3LTS, with JDK14 thus still supporting everything down
> to release=7. Based on all this, it seems it may be the case that JDK 18
> could drop support for release=7, with Java 24 then later dropping ability to
> use release=8[/9/10 if not already dropped].
> I am going to leave the configuration open-ended for the latest JDK to apply
> it to, so everything 9+, rather than guess based on the above what might
> work. At some point a newer JDK may simply fail to compile it out of the box
> with the -release 8 configuration set. Alternatively it might automatically
> target the next newest supported release and emit a warning. Regardless,
> someone in that situation presumably shouldn't care too much about targeting
> something as old as Java 8 by that point, but if they really did they would
> necessarily have to use an older JDK to do it properly either way, so this
> doesn't seem like a particular issue whichever result happens. Even in the
> 'just stops working' scenario, it should still be possible to build the old
> source with that JDK by simply overriding the targeted release property on
> the command line to a newer release version supported by the JDK in use.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
