14 janvier 2019

Migration from Java 8 to Java 9

To take advantage of all the new features brought by Java’s latest versions and embark on the release train offered by Oracle and inspired by Java 9, we have to confront a must: the migration to Java 9. This will be the most complex migration as it brings modularization; the following releases will be less spaced and therefore with have fewer features. Don’t panic! In this article, we suggest a roadmap to follow so you do not get lost on the way.

State of the place before migration 

Before the migration it is essential to make an inventory that will identify the various points to consider. You have to map the dependencies:

  • Check for each dependency if a modular version exists, 
  • Clean the dependencies, 
  • Predict version upgrades of dependencies. 

You can use the “jdeps” tool to collect information. It’s provided in the JDK since Java 8 and has been improved in Java 9. This tool analyzes the byte code and can help you:

  • Choose the migration strategy,
  • Have a better scope of the task, 
  • Know the dependencies, 
  • Know the split packages, 
  • JDK and APIs that are no longer accessible offer an alternative, if already existed. 

There are different formats for rendering the report, including the .dot format which can be used by tools such as”GraphViz” to create an image of dependencies allowing it to be more meaningful.

Many options are available on “jdeps”, it is possible to list them using the -h option, here are some:


Let’s take a look at the different strategies that you can put in place. 

No migration?

There are still rare applications running in Java 4/5 that date from 2004, a few more applications in Java 6 and many in Java 7.

The solution would be not to migrate and stay in Java 8 but the problem is that there will be no more free Oracle support starting 2019.

This will require attention because there will be no more free updates to the JRE, which includes all the fixes and new features of the JVM but also those related to security and performance.


Two strategies are possible : 

  • Module conversion of a jar

It will be necessary to add a file module-info which makes it possible to fix the name of the module and the dependencies. This will allow its use in the module-path and this declare it as another module dependency. Its use will always be possible via the classpath.s

  • Without module conversion 

It will be necessary to fix the name of the module with the attribute “Automatic-Module-Name” in the file MANIFEST.MF (otherwise the name of the module is determined by name of the jar).

Some difficulties of this migration

  • The identifier_ is no longer valid
  • Some features of the JVM have been removed with the modules:
    • The rt.jar and toolds.jar files,
    • Extension mechanism
    • Endorsed mechanism
  • The alignment of the structure of the JDK and the JRE
  • Internal APIs are now encapsulated and are no longer accessible. These APIs are nonstandard / unsupported and should never have been used and accessed, some are replaced (ex: sun.misc.BASE64Decoder). To check the use of internal APIs, it is possible to use jdeps with the -jdkinternals option which will list the internal APIs used on the classes and offer an alternative method if it exists.
  • Split packages :
    • they are the packages with same names in several jars. It was possible and quite common with the use of classpath but Java 9 prohibits them and this, to ensure a certain reliability of the configuration. For now, this only applies to modules and not to the unnamed module which still allows compatibility.
  • The new version format(s):  

The version is sometimes used for the wrong reasons (if such version, such action is made …), which makes the migration difficult.

Its format will change with Java 9: ​​there is more than 1.XX, from now on it will be in the form 9.XX.

It will therefore be difficult to find use in the version number code because there is currently no standard API that searches the source code to retrieve all uses of the old version format.

The format will still evolve in Java 10 but will remain globally compatible with the format used in Java 9. It must now go through the API Runtime.Version to know Java’s used version.


As you can see, the migration to Java 9 is not as simple as the Java 7 application to version 8. Despite the problems that this migration may offer, it will allow much better control of our applications and manage all dependencies and libraries in a better manner. In addition it will be a mandatory step to enjoy all the new features of the Following versions. You will be able to have a preview in our next article : The novelties of Java 10. 

Useful links

Écrit par


Submit a Comment

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *