16. Java 11 Transition

Overview

When writing this, Java Design Patterns version 1.22.0-SNAPSHOT supports Java 8. Breaking it down it means that the source code uses up-to Java 8 features, the code is built using Maven Compiler Plugin with target version of 1.8 and the code is executed using Java 8 runtime.

After Java 9 was released in 2017-09 there was a drastic change in Java's release schedules. New version would be released every 6 months instead of the old 2 years. New releases would be either rapid releases (supported only for 6 months) or LTS (long-term-support) that would be supported for longer time. The latest release at the moment is Java 13 (rapid release) that was released just a few days ago. The latest LTS version is Java 11. Naturally after Java 8 we want to move to the next LTS version.

Background Material

https://blog.codefx.org/java/planning-your-java-9-update/

https://blog.codefx.org/java/java-9-migration-guide/

https://www.infoq.com/articles/upgrading-java-8-to-12/

https://winterbe.com/posts/2018/08/29/migrate-maven-projects-to-java-11-jigsaw/

Preparing for the Transition

• Find out the minimum Maven version that supports Java 11 (see https://www.infoq.com/articles/upgrading-java-8-to-12/) #941
• Update Maven plugins such as compile, surefire and failsafe to newer versions so that they support Java 11 (see https://winterbe.com/posts/2018/08/29/migrate-maven-projects-to-java-11-jigsaw/) #943
• Get rid of current compiler warnings, especially the ones that warn about deprecation #944
• Run the regular build entirely on the newer JDK in a way that lets us gather all errors instead of stopping the build to the first failure (see https://blog.codefx.org/java/planning-your-java-9-update/) #948
• Build the project using the old JDK, but try to run it against a newer runtime and record the errors (see https://blog.codefx.org/java/planning-your-java-9-update/) #949
• There’s a tool, JDeps, that’s part of the JDK that you can run with a flag of -jdkinternals to check to see if a set of classes is using something it shouldn’t. Run JDeps on the project and its dependencies (see https://blog.codefx.org/tools/jdeps-tutorial-analyze-java-project-dependencies/) #950
• Java EE, Corba and JavaFX have been deprecated in newer JDK versions. Are there any dependencies to those? (see https://blog.codefx.org/java/java-9-migration-guide/) #954
• Casting to URLClassLoader no longer works. Do we have that in this project? (see https://blog.codefx.org/java/java-9-migration-guide/) #956
• Java runtime layout has drastically changed in JDK9. Do we have dependencies to old runtime such as rt.jar tools.jar or dt.jar? (see https://blog.codefx.org/java/java-9-migration-guide/) #961
• Option -Xbootclasspath has been removed. Do we have this in this project? (see https://blog.codefx.org/java/java-9-migration-guide/) #962
• System property java.version syntax has been changed, earlier 1.x now something like 9.x.x. Does something depend on the old format? (see https://blog.codefx.org/java/java-9-migration-guide/) #963
• Upgrade dependencies so that they support Java 11 (see https://www.infoq.com/articles/upgrading-java-8-to-12/ and https://winterbe.com/posts/2018/08/29/migrate-maven-projects-to-java-11-jigsaw/) #964
• Check if we are importing sun.* or com.sun.* These imports need to be replaced since they don't work in newer JDK versions anymore. #965
• Do we use currency formats that could cause problems (see https://winterbe.com/posts/2018/08/29/migrate-maven-projects-to-java-11-jigsaw/) #966

Switch from JDK8 to JDK11

• Configure Maven plugins to use Java 11 and verify that build works using JDK11 (see https://winterbe.com/posts/2018/08/29/migrate-maven-projects-to-java-11-jigsaw/ and https://www.baeldung.com/maven-java-version) #976
• Update Travis configuration to use JDK11 #973

After the Transition

• Update wiki documentation
• Java 9 introduces a new module system. What does it mean for this project? (see https://blog.codefx.org/java/java-9-migration-guide/) #955
• Maven Enforcer plugin can be used to enforce the used Java version. Enforce Bytecode Version is allowing to check that your project dependencies aren’t built for a Java version higher than the one you are targeting.
• Start using local-variable type inference (var). It is a nice example of syntactic sugar that helps reduce boilerplate code (see https://www.infoq.com/articles/upgrading-java-8-to-12/ and https://winterbe.com/posts/2018/09/24/java-11-tutorial/) #984
• Convenience Factory Methods for Collections make it significantly easier to create collections like lists, maps and sets (see https://winterbe.com/posts/2018/09/24/java-11-tutorial/) #985
• Collecting to unmodifiable collections is possible using the new Collector for Streams operations to put the results into an immutable collection (see https://www.infoq.com/articles/upgrading-java-8-to-12/)

Predicate::not provides an easy way to negate predicate lambdas or method references, again reducing the boilerplate in our code (see https://www.infoq.com/articles/upgrading-java-8-to-12/)

New methods on Optional give even more options for coding in a functional style when using an Optional instead of having to use clumsy if statements (see https://winterbe.com/posts/2018/09/24/java-11-tutorial/)

Streams have new methods ofNullable, dropWhile, takeWhile (see https://winterbe.com/posts/2018/09/24/java-11-tutorial/)

String has new helper methods (see https://winterbe.com/posts/2018/09/24/java-11-tutorial/)

InputStream finally gets a super useful method to transfer data to an OutputStream (see https://winterbe.com/posts/2018/09/24/java-11-tutorial/) #987

• JShell is the REPL that allows us to run individual lines of code, or even scripts, in Java. It’s a nice way to experiment with new features, and we can use it locally on our development machines without having to adopt new versions of Java in our production application code. Can we utilize that?
• HttpClient built in to the JDK. Can we utilize this? (see https://winterbe.com/posts/2018/09/24/java-11-tutorial/) #988
• Multi release jar files is one of the tools library developers can use to support the needs of those using the latest versions of Java as well as those forced to use older versions. Can we utilize that? (see https://www.infoq.com/articles/upgrading-java-8-to-12/)
• JLink is a fantastic tool made possible by the Java Module System which lets us package and deploy only the sections of the JDK that we really need. Can we utilize it? (see https://www.infoq.com/articles/upgrading-java-8-to-12/)
• The default Garbage Collector has been changed to G1. Does this affect us?
• The improvements in recent versions of Java can lead to a cost reduction. Not least of all tools like JLink reducing the size of the artifact we deploy, and recent improvements in memory usage could, for example, decrease our cloud computing costs.