Details
-
Task
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
None
-
None
Description
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.
Attachments
Issue Links
- relates to
-
-
- Closed
-