Over a million developers have joined DZone.

Hot Shot 004: Migration Advice for Java 10 [Podcast]

DZone's Guide to

Hot Shot 004: Migration Advice for Java 10 [Podcast]

Settle in for this 14-minute podcast to get some advice for embracing the JMPS in Java 9 and how to migrate your code base to Java 10.

· Java Zone ·
Free Resource

Delivering modern software? Atomist automates your software delivery experience.

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

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

At the time of writing, I would recommend that it is far easier to migrate software architecture that is written as strict microservices rather than legacy monolithic systems. Why is this so? Microservices can be adapted and changed one-by-one or in defined groups of work. For this to work, your microservices must be independent of each other, which means they rely on a REST API, or XML over SOAP or 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.


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 to 3.7.0 or better. The Gradle delivery team has a 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. Building Java 9 Modules has all of the details and is well worth 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 Java 9 support is probably incoming and expected soon. Many professional server side teams rely on Hibernate, Spring Framework, Spring Boot, and other aspects of Java EE. Worst of all is that the actual servlet containers, because every engineering relies on one of them, works with Java 10. So 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 has written anecdotal support of OpenJDK 9 in their last release for Spring Boot 2.0, so you might be lucky there.


Finally, knowledge of the Java module system is going help in the long-term. Because, eventually, all of the most important frameworks and libraries are going to be modularized, engineers will have to understand the concepts of:

  • Split packages: Every module in Java 9 must contain unique packages. Many JARs in legacy and current code bases probably have split packages — the same package appears in one or more JAR. This probably includes open source and commercial third-party libraries. Your main 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 will handle their work.
  • Automatic modules: Know the process of how Java 9 automatically exports a JAR from the classpath as a module.
  • Unnamed modules: This involves loading class outside of the module system, from the class path. A class that 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 classes across modules.
  • Open module: This concept allows modules to be inspected during runtime.
  • Provision module: This  defines transitive dependencies between modules.
  • Modularized resources: This defines the resources restricted to modules. If 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 code bases against Java 8 (no 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 out a general report.

That’s all. Enjoy the ride!

Here are the references to information inside this article:

Start automating your delivery right there on your own laptop, today! Get the open source Atomist Software Delivery Machine.

java ,java 10 ,java 9 modules ,code migration

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}