Robbie Gemmell created QPIDJMS-497:
--------------------------------------
Summary: 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
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]
