Java 10 migration: Is it a breeze or a tornado?
© Shutterstock / solarseven
Java 10 was released a couple of weeks ago but we’re still dissecting its most important feature(s), as well as the features that didn’t make the cut. Now it’s time to talk about migration. Is it a breeze or a tornado? Let’s see what our 11 interviewees have to say.
“It is not easy at all for infrastructure providers to move up to the latest JDK”
Java 10 was released a couple of weeks ago but we’re still dissecting its most important feature(s) (*cough*Local-Variable Type Inference*cough*), as well as the features that didn’t make the cut. Now it’s time to talk about migration. Is it a breeze or a tornado? Our 11 interviewees will weigh in on this issue in a moment.
Java 9 will also make an appearance in today’s interview because even though Java 10 is here, we’d like to know whether our Java heroes have migrated to Java 9 or have chosen to skip it entirely — this question is especially relevant to us since our recent poll showed that a lot of developers are still using Java 8.
We keep circling back to the Java SE support roadmap but it’s important to realize that Java SE 9 and 10 are short-term releases. Therefore, users are encouraged to transition to the next release when available. In short, this means that if you don’t give them a chance when they are out, you won’t have another shot at playing with them later on.
Don’t miss the first two parts of our Java 10 interview series:
Back to our interview series!
11 answers: Will you be migrating to Java 10 anytime soon?
Meet our Java experts
Donald Smith: I’ve already made Java 10 my base JDK for demos and presentations.
The question is not when we will migrate to Java 10, but when we will migrate to Java 8 for IMDG?
Greg Luck: Hazelcast has two open source projects: Hazelcast In-Memory Data Grid, by which we are best known, and a new one Hazelcast Jet, a stream processing engine. Hazelcast IMDG is at language level Java 6 while Jet is as Java language level 8.
Hazelcast IMDG has 49MM phone homes a month — huge installed base. As of end February 2018, 95% of Hazelcast IMDG users on 3.6 or higher are using Java 8. This up from 77% in September 2016. So, the question is not when we will migrate to Java 10, but when we will migrate to Java 8 for IMDG?
For Jet, we only released the first public release in February 2017. We will upgrade to a new version of Java if there are enough attractive features to warrant it.
And to me, this underlines a serious problem with the rapid release of Java versions. While it is easy for applications to move up to the latest JDK, it is not easy at all for infrastructure providers to do so because of their need to accommodate the installed base.
Simon Ritter: I will certainly use it for demo code I write. Since I don’t write production code anymore, I have more flexibility on which JDK I can use, and I don’t need to be quite so concerned about updates.
Lukas Eder: jOOQ will support it, yes. And the jOOQ integration tests are probably going to be migrated to Java 10, as they, too, will profit from JEP 286.
Trisha Gee: I’ve already been writing some example code in it. It’s possible I might migrate some of my demos to Java 10 to see if it has any major impact on the readability or performance of the code.
Markus Eisele: I’ve been using it for some time already. Test early, test often they say. And I believe that everybody should start using the beta versions as soon as they get released. Spotting difficulties and bugs is a community effort.
Marcus Biel: As a Java influencer, I have obviously already experimented with the Java 10 early access version, and I will be migrating as soon as possible. But my clients just upgraded to Java 8, so Java 10 will have to wait a bit longer, unfortunately.
Wayne Citrin: Our products have to run on all versions of Java starting with Java 5. We’ve tested our products against Java 10, and there are no breaking changes, but we currently don’t plan to actually rebuild our products with Java 10.
David Heffelfinger: I may migrate on some of my personal projects. I work as a consultant and most of my clients are large, conservative organizations that are very risk-averse, for that reason most of them will probably not migrate to Java 10 for some time.
Nicolai Parlog: Yes. It’s fairly easy and there are no more public updates for Java 9, so it’s a no-brainer.
Richard Gall: No. Play with it. After all, Java 10 is not a long-term support version.
Did you migrate to Java 9? How was the process?
Greg Luck: For both IMDG and Jet, we have checked that they build and run on Java 9.
Hazlecast IMDG 3.10 and Hazelcast Jet 0.6 both coming out in April will support Java 9. But neither will use the Java 9 language level.
For Jet, we carefully examined Java Modularity to see if we could add it in so that it would be recognized by Java 9 but not break Java 8. That doesn’t work. You get the following compiler error if you try it.
Error:(1, 1) java: modules are not supported in -source 1.8
(use -source 9 or higher to enable modules)
So, no module-info.java. But if someone tries to use non-modularized code from Java 9, by adding the library to the module path, then it will be made available. This is called Automatic Modules. However, the name used for the automatic module is the jar name.
A good practice and one we have added to our new releases is to create stable names for these automatic modules. This is done by adding an Automatic-Module-Entry entry to our Jar manifests.
Our stable names are:
Another problem with the module system in Java 9 is that a package must be fully contained in one module. Sounds like a good idea. But practically we have some code with the same packages in our clients and our server side. So, this breaks the module system. This, therefore, requires us to do a major refactoring.
We also have other things like Management Center and our many modules. Management Center is being upgraded to Java 9 in the 3.10 release. Individual modules will also be upgrading their language levels driven by the communities that use them.
Simon Ritter: I used JDK 9 for some demos. On the whole, I found it pretty straightforward. I think if you use internal APIs (like sun.misc.Unsafe) either directly or indirectly (via a framework or third-party library), it would require more work.
With IntelliJ IDEA, migration to Java 9 modules is a charm!
Lukas Eder: jOOQ has to support Java 9 (although as of version 3.10, it’s not modularized yet). Our other libraries, including jOOλ, jOOR, jOOU, jOOX are already modularized and published as cross-release artefacts for those who need that. The latter four libraries were straightforward to modularize.
jOOQ isn’t, as it internally depends on JAXB. It’s not easy for a library vendor to upgrade to Java 9 and get everything right, but for end users, I think the process is rather straightforward. There are tons of good blogs out there documenting the caveats. My favorite is Nicolai Parlog’s, whom I’ve interviewed recently.
Trisha Gee: Yes I did. It was quite painful because I did it very early on, a year before the actual release, so many of the tools and libraries I use didn’t fully support Java 9. But it was worth it to
a) get an early view of Java 9, how it feels to use, what the pain points might be (and report bugs and other issues back too!) and
b) help provide useful feedback to those tools and libraries that didn’t work with Java 9 so that they could be ready by the time Java 9 was released.
I believe that migrating to Java 9 now with the version that was released in the end, plus the support of the tools and libraries as they are now, would be relatively straightforward.
Markus Eisele: I’ve done a couple of local tests of my own pet projects but nothing serious enough to call it a process. I’ve basically followed the official Oracle guide and it went smoothly.
Marcus Biel: I migrated my own projects to Java 9 last year. With IntelliJ IDEA, migration to Java 9 modules is a charm! Working with Eclipse Oxygen and Java 9 modules is not as smooth, but this will probably improve with the next version.
Wayne Citrin: We are currently building our code against Java 8, but we have tested our compiled products against Java 9 and they work just fine. There was one breaking change due to changes to the version numbering API and schema, but it was easily fixed. I’m excited by Java 9’s multi-release JAR file feature, but since we haven’t yet needed to take advantage of Java 9- or Java 10-specific language features, we haven’t had to use it yet. I’m sure we will soon.
David Heffelfinger: I did migrate to Java 9 in some of my projects. However I work primarily with Java EE, and some Java EE application servers do not run properly on Java 9, for that reason, some of my projects are still using Java 8, the risk aversion of many of my clients also keeps me on Java.
Nicolai Parlog: Ehm. Intense? :) The larger the code base, the more migration challenges you are likely to encounter and many of them feel like freak accidents — I had plenty of those. Fixing them almost always meant paying down some technical dept, though, and so I feel that the time was well-invested.
Richard Gall: Indefinite. There are projects that I have some finger in that migrated, mainly FOSS. Others stayed with Java 8 or Java 6.
In the fourth part of our interview series (two more to come), our interviewees weigh in on the new release cadence and reveal whether legacy developers should worry about how they can take advantage of Java 10.
12 JEPS for Java 10
- (JEP 286) Local-Variable Type Inference: Enhances the Java Language to extend type inference to declarations of local variables with initializers. It introduces var to Java, something that is common in other languages.
- (JEP 296) Consolidate the JDK Forest into a Single Repository: Combine the numerous repositories of the JDK forest into a single repository in order to simplify and streamline development.
- (JEP 204) Garage Collector Interface: Improves the source code isolation of different garbage collectors by introducing a clean garbage collector (GC) interface.
- (JEP 307) Parallel Full GC for G1: Improves G1 worst-case latencies by making the full GC parallel.
- (JEP 301) Application Data-Class Sharing: To improve startup and footprint, this JEP extends the existing Class-Data Sharing (“CDS”) feature to allow application classes to be placed in the shared archive.
- (JEP 312) Thread-Local Handshakes: Introduce a way to execute a callback on threads without performing a global VM safepoint. Makes it both possible and cheap to stop individual threads and not just all threads or none.
- (JEP 313) Remove the Native-Header Generator Tool: Remove the javah tool from the JDK since it has been superseded by superior functionality in javac.
- (JEP 314) Additional Unicode Language-Tag Extensions: Enhances java.util.Locale and related APIs to implement additional Unicode extensions of BCP 47 language tags.
- (JEP 316) Heap Allocation on Alternative Memory Devices: Enables the HotSpot VM to allocate the Java object heap on an alternative memory device, such as an NV-DIMM, specified by the user.
- (JEP 317) Experimental Java-Based JIT Compiler: Enables the Java-based JIT compiler, Graal, to be used as an experimental JIT compiler on the Linux/x64 platform.
- (JEP 319) Root Certificates: Provides a default set of root Certification Authority (CA) certificates in the JDK.
- (JEP 322) Time-Based Release Versioning: Revises the version-string scheme of the Java SE Platform and the JDK, and related versioning information, for present and future time-based release models.