Interview series with Java influencers — Part 3

Is JDK 11 migration a given, due to planned long-term support?

Gabriela Motroc
© Shutterstock / Radachynskyi Serhii

Last week, our eight Java influencers described their favorite Java 11 feature(s) and weighed in on everything that has been axed [or deprecated]. Now it’s time to discuss the importance of Java 11 [and if it can convince developers to “drop” Java 8]  and the fact that the ‘public updates’ tap for Java 8 business users will be turned off in January 2019.

“Java 11 will be the first real migration milestone for many projects”

That’s it, folks! “It’s time to upgrade,” Quentin Adam said when we talked about the fact that the ‘public updates’ tap for Java 8 business users will be turned off in January 2019. Martin Thompson also explained  that “Java 11 has some nice refinements but no killer feature to drive adoption.”

Java 11 is the next planned LTS (long-term support) release; is this the only reason why developers might want to give it a try? Let’s find out!

Java 11 is the next planned LTS release. Is this the only reason why you wish to migrate?

Loading ... Loading ...



8 answers: A lot of developers are still using Java 8. What does this mean for Java 11 adoption? Do you think Java 11 will be important or big enough to make them want to drop Java 8?

Meet the Influencers

Markus Eisele (@myfear) is the Director of Developer Advocacy at Lightbend and a Java Champion.

Jessica Kerr (@jessitron) is Lead Engineer at Atomist.

Guillaume Laforge (@glaforge) is Developer Advocate for Google Cloud Platform, Apache Groovy PMC Chair at The Apache Software Foundation and Java Champion.

Lukas Eder (@lukaseder) is the founder and head of R&D at Data Geekery GmbH, the company behind jOOQ and a Java Champion.

Josh Long (@starbuxman) is the Spring Developer Advocate at Pivotal. He is the author of 5 books and 3 best-selling video trainings. He is also a Java Champion.

Eberhard Wolff (@ewolff) is a Fellow at INNOQ and a software architect.

Martin Thompson (@mjpt777) is a consultant, trainer, and coach specializing in designing high-performance and low-latency systems. He is also a Java Champion.

Quentin Adam (@waxzce) is the CEO of Clever Cloud.

Markus Eisele: This particular situation isn’t exactly about “importance” for developers. I think that feasibility is the bigger challenge. Companies have postponed migration from 8 to 9 because of the complexity of the module system. This also has been a dot-zero release which barely makes it into production.

If they have switched, it was used without modularity at all. The same situation was true for 10. With 11 enforcing modularity, this will be the first real migration milestone for many projects. We now have a reasonable number of experiences about how to use the module system and how to migrate and build new software on top. My guess is that Java 8 to 10 will be treated as legacy until these projects are needed and new projects are set up with Java 11 from the beginning.

Jessica Kerr: Nope. They can catch up at the pace their company chooses to move at.

Guillaume Laforge: It’s possible that developers and enterprises will stick to Long Term Support versions, and target those versions for their next upgrades, rather than upgrading every 6 months.

It’s possible that developers and enterprises will stick to Long Term Support versions, and target those versions for their next upgrades.

At customers’ companies I’ve worked with, it was often a big IT decision to move to a newer version of the JDK. However, it’s probably less the case as more companies are containerizing their workloads and using the cloud more and more.

So we’ll have to see if the more wide-spread DevOps practices, Cloud Native approaches, also help companies upgrade more rapidly, or if they’ll still stick to a slower upgrade pace.

I don’t have a crystal ball, sorry!

Lukas Eder: Not from a functionality perspective, but Oracle’s ending free Java 8 LTS soon will have an impact. I’ve heard from quite a few clients that they’re considering using OpenJDK soon, but the operations implications of such a change in enterprises are substantial, so I’m not really sure what’ll happen in early 2019.

Josh Long: I think so. A lot of organizations have parked their old applications at Java 8 because it’s supported. Java 11 rolls up all the interesting features in earlier releases and represents a reasonable place to replatform, assured in the stability of the release for a while.

Eberhard Wolff: As Java 11 has long-term support, it is likely that even conservative developers will eventually migrate to Java 11. The new features are not that huge from a developer’s perspective so I don’t think they provide enough motivation to migrate to a new version immediately.

Martin Thompson: Java 11 has some nice refinements but no killer feature to drive adoption. Java 5 had Generics and Java 8 had Lambdas. In the history of Java, those were the only two releases I’ve seen people get excited about. Without a major feature, people need a very smooth upgrade path otherwise they will wait. Right now I’m seeing people completing their migration to Java 8 and they have little appetite for any upgrades that are not easy.

SEE ALSO: The power list: Top 20 Java influencers of 2018

Quentin Adam: Java 9 introduced Jigsaw, which was great and useful, but all the marketing message was just on this and how difficult it was to use the modules. And lots of users focus only on this and see the migration as a very difficult project, slowing down the adoption.

I think many of the Java ecosystem leaders working on alternate languages, on builder tools or on CI projects carry lots of responsibilities on this. Because the difficulty of a language port is way higher than just following with a traditional Java application. But a new feature like ZGC and shorter release cycle will resume the update cycle and after a few months, we will see new version adoption grow again.


Speaking of Java 8, public updates will remain available for individual, personal use through at least the end of 2020 but business users won’t be that lucky — the ‘public updates’ tap will be turned off in January 2019. A lot of Java developers believe that this decision is “ruining Java”. What’s your take on that?

Markus Eisele: It won’t be a big issue for companies that are Oracle customers already. I can imagine corporate licenses and bundles. The problem will be solved for them. Other alternatives from Red Hat or IBM are just around the corner. There will be some way to get support for Java legacy. It is a change in process but I don’t see this as something that ruins Java.

Keeping software running as computers and people change is expensive.

Jessica Kerr: If by “ruining Java” they mean “taking away my ability to live in the past forever and expect everything to continue to work” then yes, they’re right. Keeping software running as computers and people change is expensive. Software is not a capital expenditure, and as long as we model it that way, we will feel dissonance.

Lukas Eder: Who are those “a lot of Java developers”? Because I haven’t met them.

There’s the OpenJDK and other vendors are free to apply security updates to any old Java version. Besides, it’s perfectly OK to ask money for such services, after all, if you don’t want to pay money, just upgrade to the latest version, which is still free.

I think that the changes will benefit Java and the community.

Josh Long: Java 8 was released in 2014 and resources are finite. I don’t think it’s reasonable to expect that  old iteration of software be supported in perpetuity. We on the Spring team release new releases all the time and try to be as accommodating as possible in supporting older iterations. At some point, you just have to hope people will see value in what you do and upgrade. No single change in any recent release of Java threatens the stability of your production application. Sure, there are some issues that will take a solid ten to fifteen minutes of Googling, but they’re solvable and well-understood problems.

Eberhard Wolff: We’ll see. Outdated Java versions in production are actually quite common. Of course, it would be great to get free supported Java version for a much longer period of time. However, to continue Java’s success it must be a commercially viable platform. That means there must be some revenue to justify the investments. So I think it is fair to ask for money for the additional support timespan.

Also, there is still the OpenJDK so the community can work on the problem if they are not pleased with what Oracle does.

SEE ALSO: Meet Jib: Containerizing a Java application has never been easier

Martin Thompson: This is an interesting change in strategy for Java. Java as a platform has always been freely available which is one of the reasons I believe it has been a success. I can see the need for Oracle wanting to commercially benefit from Java but they need to be careful and choose wisely.

Outdated Java versions in production are actually quite common.

Given .Net Core is now available on Linux and freely available, then it is a risky time for Java. C# is currently a more elegant language but it does not have the ecosystem of Java. Microsoft are taking steps to open .Net and expand its ecosystem and it proved a nice platform for Serverless. Java is difficult to influence from outside Oracle and is becoming less available with the proposed changes.

Quentin Adam: Oracle doing Oracle. They are here to make money, and pay for support on old release is a battle-tested business model. But in any case, it’s a good way to force organizations to move to the next Java release. If the support of old versions is too long, the risk is to stop adoption, and nobody wants Java 8 to be our Python 2. So that’s it. It’s time to upgrade!


Next week, we’ll talk about the soon-to-be-deprecated Nashorn JavaScript engine and ZGC.

If you’d like to meet the top Java movers and shakers, join us in London in October.


17 features for JDK 11

Just to freshen up your memory, JDK 11 includes the following features:

181: Nest-Based Access Control

Introduce nests, an access-control context that aligns with the existing notion of nested types in the Java programming language. Nests allow classes that are logically part of the same code entity, but which are compiled to distinct class files, to access each other’s private members without the need for compilers to insert accessibility-broadening bridge methods.

309: Dynamic Class-File Constants

Extend the Java class-file format to support a new constant-pool form, CONSTANT_Dynamic. Loading a CONSTANT_Dynamic will delegate creation to a bootstrap method, just as linking an invoke dynamic call site delegates linkage to a bootstrap method.

315: Improve Aarch64 Intrinsics

Improve the existing string and array intrinsics, and implement new intrinsics for the java.lang.Math sin, cos and log functions, on AArch64 processors.

318: Epsilon: A No-Op Garbage Collector

Develop a GC that handles memory allocation but does not implement any actual memory reclamation mechanism. Once the available Java heap is exhausted, the JVM will shut down.

320: Remove the Java EE and CORBA Modules

Remove the Java EE and CORBA modules from the Java SE Platform and the JDK. These modules were deprecated in Java SE 9 with the declared intent to remove them in a future release.

321: HTTP Client (Standard)

Standardize the incubated HTTP Client API introduced in JDK 9, via JEP 110, and updated in JDK 10.

323: Local-Variable Syntax for Lambda Parameters

Allow var to be used when declaring the formal parameters of implicitly typed lambda expressions.

324: Key Agreement with Curve25519 and Curve448

Implement key agreement using Curve25519 and Curve448 as described in RFC 7748.

327: Unicode 10

Upgrade existing platform APIs to support version 10.0 of the Unicode Standard.

328: Flight Recorder

Provide a low-overhead data collection framework for troubleshooting Java applications and the HotSpot JVM.

329: ChaCha20 and Poly1305 Cryptographic Algorithms

Implement the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539. ChaCha20 is a relatively new stream cipher that can replace the older, insecure RC4 stream cipher.

330: Launch Single-File Source-Code Programs

Enhance the java launcher to run a program supplied as a single file of Java source code, including usage from within a script by means of “shebang” files and related techniques.

331: Low-Overhead Heap Profiling

Provide a low-overhead way of sampling Java heap allocations, accessible via JVMTI.

332: Transport Layer Security (TLS) 1.3

Implement version 1.3 of the Transport Layer Security (TLS) Protocol.

333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)

The Z Garbage Collector, also known as ZGC, is a scalable low-latency garbage collector.

335: Deprecate the Nashorn JavaScript Engine

Deprecate the Nashorn JavaScript script engine and APIs, and the jjs tool, with the intent to remove them in a future release.

336: Deprecate the Pack200 Tools and API

Deprecate the pack200 and unpack200 tools, and the Pack200 API in java.util.jar.

Gabriela Motroc
Gabriela Motroc was editor of and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Inline Feedbacks
View all comments
Elhanan Maayan
Elhanan Maayan
3 years ago

i’m assuming the 56% who want to upgrade to LTS, most of them, aren’t aware it will be paid LTS

Anna Martinez
Anna Martinez
3 years ago

Thank you, Gabriela, for sharing such an amazing article.
I was really glad to hear about the new features for Java JDK 11 you shared for us on Jaxenter.
Being a Java Developer I will surely implement this new features for my upcoming Java codings.
For more information please check my portfolio:

3 years ago

Hi Markus Eisele,

Thanks for your post.

Can you please explain about this?
With 11 enforcing modularity, this will be the first real migration milestone for many projects.

My understanding is, we don’t have support for classpath. That’s the reason in java11 there is no JRE release. So you mean that, we are enforced to use modularity.

Is my understanding correct?