[
https://issues.apache.org/jira/browse/QPIDJMS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved QPIDJMS-497.
------------------------------------
Resolution: Fixed
> add maven.compiler.release configuration on JDK9+
> -------------------------------------------------
>
> Key: QPIDJMS-497
> URL: https://issues.apache.org/jira/browse/QPIDJMS-497
> Project: Qpid JMS
> Issue Type: Task
> Reporter: Robbie Gemmell
> Assignee: Robbie Gemmell
> Priority: Minor
> Fix For: 0.51.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]
