Reading time:

4 minutes

Word count:

842

This are my verbatim notes to the PEAT UK podcast:

Hot shot 004 – Migration Advice for Java 10

Hello there once again to another hot shot. My name is Peter Pilgrim, Platform engineer and DevOps specialist, Java Champions.

As you know Java 9 introduced a module system. You probably are migrating your services to JDK 10 and beyond or at least thinking. My general advice to business is, the sooner you migrate the better your technical debt will be. It will be easier to stay up to changes when Java 11 is released in September 2018.

At this time of writing, I would recommend that it far easier to migrate software architecture that are written as strict micro-services over legacy monolithic systems. Why is this so? Micro services can be adapted and changed one-by-one or defined groups of work. For this to work, your micro services must be independent of each other, which means they rely on a REST API, or XML over SOAP over HTTP communication or some other remote invocation protocol.

The biggest impediment to migration are tools, stack dependencies and know how. Let’s unpack each of these for a little bit.

Tools – all of the major IDEs now have support for Java 10. These are NetBeans, Eclipse and IntelliJ 2018. So there shouldn’t be an issue compiling basic Java programs. Most of us professionals tend to rely on build tools, which are Gradle and Apache Maven. If you rely on Maven, you need to change the compiler plugin version 3.7.0 or better. The Gradle delivery team has handy guide on that explains how to add manual support to an example project. Be aware that the current Gradle release version 4.6, at the time of writing, does not have first class support. Unfortunately, Gradle requires a lot of faffing around to get Java 9 support. The Building Java 9 Modules has all of the details and is well reading if you want to get Java 9 module support into your team’s build now.

Stack dependencies – the biggest impediment is dependencies of libraries. If they are open source then probably Java 9 support is incoming and expected soon. Many professionals server side teams rely on Hibernate, Spring Framework, Spring Boot and other aspects of Java EE. Worse of all, is that the actual servlet containers, because every engineering relies on one of them, works with Java 10. So check I strongly recommend that you personally verify that Tomcat, Payara and WildFly actually execute on a Java 10 runtime environment. It should execute in the vanila state without any deployed WAR files. Pivotal have written anecdotal support of OpenJDK 9 in their last release for Spring Boot 2.0, you might be lucky there.

Finally, the knowledge of Java module system is going help in the long-term. Because eventually all of the most important frameworks and libraries are going to be modularised, why would a Dev Ops / Platform Engineer delay learning about the module system.

Engineers will have to under the concepts

• Split packages – every module in Java 9 must contain unique packages. Many JAR in work legacy and current code base probably have split packages, the same package appears one or more JAR. This probably include open source and commercial third party library. Your main progressive work is, then, to refactor and re-architect the modules that you own, the third party vendors and library team are responsible for their software and they will do theirs.
• Automatic modules – this concept of Java 9 automatically exporting a JAR from the classpath as an module
• Unnamed modules – this concept of loading class outside of the module system but from the class path. A class which is not a member of a ‘named module’ is considered to be a member of a special module known as the unnamed module
• Service discovery – the Service API in JDK 9 was improved to load class across modules.
• Open module – this concepts allows modules to be inspect during runtime
• Provision module – this concept defines transitive dependencies between modules
• Modularised resources – the concept defines loading resources is now restricted to modules. You need a resource in another module, then you must explicitly provision in the module-info.java file
• Module and class path hell – unfortunately, library writers must test their codebase against Java 8 (non modules) and Java 10 (modules) across the module path and class path. This is the biggest drawback for migration.

My first recommendation is to find those split packages. I wrote a piece shell script and Python to help me figure a general report.

That’s all. Enjoy the ride

Here are the references to information inside this article:

• Building Java 9 Modules in Gradle
• State and Future of Gradle
• Spring Boot and Java 9
• This week ins Spring (26th September 2017)
• Hibernate support for Java 9
• Tomcat JDK 9 requirements and download
• WildFly 11 an OpenJDK 9 works together

+PP+
April 2018

By the way, all your Shares, Likes, Comments are always more than welcomed!

(I know some of this verbatim text is ad lib a bit in this podcast. Thanks in advance *PP* 🙂