Java Runtime has recently been licensed by Oracle for a fee. There is also a free version: OpenJDK. At BusinessCode, we advise our customers to change over to it. But first we want to take a closer look and summarize our experiences. Our colleague Eugen Plischke has dealt with the conversion in more detail and has written down his experiences.
There are 2 ways to “migrate” a project to Java12
(A): Establish compatibility
Some components that were part of the core of Java Runtime are no longer shipped with Java12, so they have to be manually added to the project. Many of these dependencies have been individually developed and distributed, each with independent version numbers. Depending on which of these features are used in the project, these (libraries) must be imported individually.
These libraries in turn have their own lifecycle. They are treated like “normal” third-party libs and must be obtained in the version that is compatible with the project code. Furthermore, the project also uses other, non-core libraries. Of course, these libraries also have dependencies to these Java modules, which previously belonged to the Java kernel and are now distributed separately. The compatibility on this level cannot be determined: All issues that lead to an error during the compilation time can be addressed and adjusted. All other incompatibilities do not occur until runtime.
Conclusion: Actually every function has to be tested.
The project code itself, if it ran with Java8, also runs with Java12, as in our case. We can’t say that in general, because it depends on how you use the components that were part of the Java kernel before and are now independent and may have changes in the API.
Java has introduced a new feature: Modules. If you want to use these, you have to extend the project code to describe the modules and if necessary to organize the project code differently. This assumes, however, that other third-party libs do not get in the way and are also compatible with the new module standard. This is the case with libraries that are now pulled out of the Java kernel, but not with the other third-party libs. Java brings backwards compatibility, which didn’t work for us. At the moment we don’t know why this is the case and if it’s just an Eclipse bug.
If the project code is compiled in the Java12 target (target environment), it must implement the new module standard. To deactivate the module standard, the compile target must be set to Java8. In this case you can still compile with Java12 and the result will also run on the Java12 runtime.
(B): Introducing the Java12 standard
Furthermore, the development environment – (Eclipse) – must be able to work with the new standard. Even that was a problem until about CW27. Eclipse had bugs and prevented a clean working on the project code.
Then there is the buildchain, i.e. the packaging of the project. Depending on whether we use Gradle or ANT, this is the next building site.
Gradle:
Here you have to upgrade to Gradle Version 5.2. This is not fully compatible with version 4, which we have used in some projects so far. This means that the project code of the buildchain has to be adapted.
ANT:
Also here the existing ANT installation must be compatible to Java12. With ANT 1.9 we did not notice any problems with Java12. The project code must be extended to force compilation in Target Java8.
I have also created a document that logs the steps of the conversion.
Do you have any further questions? Then please contact us, we will be glad to help you!
Photo: Eugen Plischke