top of page

Migrating to Java 11 from 8

Updated: Feb 3, 2021

It is high time to migrate to Java 11, if you are not do it now.

Migrate #Java8 to #Java11 now itself, this post has got you covered. We discusses common migration challenges, long-term support, update preparations, version requirements, licensing and more.

I have supervised JDK8 to JDK11 migration in couple of my applications in my company very recently in January 2020. Based on that experience, I thought of sharing that knowledge through njanam.

Why is it high time to migrate

The following are some of the significant changes in JDK 11:

  • Oracle no longer offers JRE and Server JRE downloads; consequently, Auto-Update is not available anymore.

  • Oracle no longer provides a 32-bit Windows download.

  • Java Web Start, Java Plugin, and Java Control Panel are not available in JDK. See Removal of the Deployment Stack.

  • JavaFX is no longer included in the JDK. It is now available as a separate download from

  • JAXB and JAX-WS are no longer bundled with JDK. See Removal of Java EE and CORBA Modules.

In addition, there are security related updates and few removed tools and components that you need to be aware of. See:

Features Forcing US

As developers, we’re most interested in the new language features or APIs that come in each update to the language. Since Java 8 we’ve had plenty of new features, and also some new tools that can change the way we work. I’ve picked out some key features developers have told me have made their lives easier when they’re working with the latest version of Java.

Local-variable type inference (var) is an example of syntactic sugar that helps reduce boilerplate code. It’s not a fix-all for all readability problems, but using it at the right time can help the reader of the code focus on the business logic rather than boilerplate.

Convenience Factory Methods for Collections make it significantly easier to create collections like lists, maps and sets. The factory methods also create unmodifiable collections, making them safer to use.

Collecting to unmodifiable collections is possible using the new Collector for Streams operations to put the results into an immutable collection.

Predicate::not provides an easy way to negate predicate lambdas or method references, again reducing the boilerplate in our code.

New methods on Optional give even more options for coding in a functional style when using an Optional instead of having to use clumsy ifstatements.

JShell is the REPL that allows us to run individual lines of code, or even scripts, in Java. It’s a nice way to experiment with new features, and we can use it locally on our development machines without having to adopt new versions of Java in our production application code.

An HttpClient built in to the JDK. Almost everyone is working with HTTP in some form or other, via web applications or REST services or something else. The built in client removes the need for external dependencies, and supports HTTP 1.1 and 2 with both synchronous and asynchronous programming models.

Multi release jar files is one of the tools library developers can use to support the needs of those using the latest versions of Java as well as those forced to use older versions.

JLink is a fantastic tool made possible by the Java Module System which lets us package and deploy only the sections of the JDK that we really need.


Generally speaking each new release performs better than the previous one. "Better" can take many forms, but in recent releases we've seen improvements in startup time; reduction in memory usage; and the use of specific CPU instructions resulting in code that uses fewer CPU cycles, among other things. Java 9, 10, 11 and 12 all came with significant changes and improvements to Garbage Collection, including changing the default Garbage Collector to G1, improvements to G1, and three new experimental Garbage Collectors (Epsilon and ZGC in Java 11, and Shenandoah in Java 12). Three might seem like overkill, but each collector optimizes for different use cases, so now you have a choice of modern garbage collectors, one of which may have the profile that best suits your application.

Cost Reductions

The improvements in recent versions of Java could lead to a cost reduction. Not least of all tools like JLink reducing the size of the artifact we deploy, and recent improvements in memory usage could, for example, decrease our cloud computing costs.

There's always another potential benefit to consider in that using modern versions of a language also allows you to attract a wide range of developers, as many developers like to have the opportunity to learn new things and upgrade their skills. Using a modern version of Java has an impact on the retention and recruitment of developers, which ultimately impacts the cost of running your team.

The First rule of migrating to Java 11

The best way to migrate from #JDK8 to 11 is update all the things. Your IDE, your build tool & plugins, your third party library dependencies especially if your are using #Spring Framework. I recommend you to do all of these updates in advance because it will very likely get you past some hurdles thus you can then stay blissfully unaware of.

Here are the recommended minimum versions for a few tools:

  • IntelliJ IDEA: 2018.2

  • Eclipse: Photon 4.9RC2 with Java 11 plugin

  • Maven: 3.6.0

  • compiler plugin: 3.8.0

  • surefire and failsafe: 2.22.0

  • Gradle: 5.0

Dependencies that you should change:

  • Anything that operates on bytecode like ASM (7.0),

  • Byte Buddy (1.9.0),

  • cglib (3.2.8), or Javassist (3.23.1-GA).

  • Anything that uses something that operates on bytecode like Spring (5.1),

  • Hibernate (

  • Mockito (2.20.0)

  • stack traces ending in bytecode manipulation libraries

  • errors or warnings complaining about the bytecode level

  • errors or warnings mumbling about "unknown (constant pool) entries"

If you don't update in advance, it should still be the first action you take when encountering a problem with any specific tool or dependency. Either way, you may occasionally encounter problems even though your dependencies are up to date. In that case, have a look at the precise artifact causing the problem - chances are it's a transitive dependency, in which case you should look into updating it separately.

Which JDK

OpenJDK is the New Default, Oracle JDK is Fully Commercial.

Oracle's JDK was richer in features and perceived to be more stable and performant - it was hence the default choice for most of the ecosystem. OpenJDK was much less widely used but that will change with Java 11.

Oracle worked hard to make Oracle JDK 11 and #OpenJDK 11 almost identical from a technical point of view - so much so that the most important difference is the license file they ship with. Oracle further pushes developers towards OpenJDK by making their branded JDK commercial, meaning you can't use it in production without paying Oracle from day one after its release but you can use it for development and testing.

As a consequence, OpenJDK will become the new default - with full feature set, prime performance, and a free license (GPL+CE) it's a great choice. On the next rung come, side by side, Oracle and other vendors with their OpenJDK variants for which they sell long-term support.

Amazon Coretto

A new player entered the game! Amazon now offers Amazon Corretto.

Amazon Corretto is a GPL+CE-licensed OpenJDK build with free long-term support. Here are the key information:

  • based on OpenJDK, plus security/performance/stability/bug fixes implemented by Amazon

  • support for Linux, macOS, Windows

  • free to use, GPL+CE licensed

  • long-term support for #Java8 until at least 2023

  • long-term support for #Java11 starting in 2019 until at least 2024

  • quarterly updates with possible intermittent urgent fixes

Regarding contributions to OpenJDK, the FAQ says, that "Amazon started contributing to OpenJDK in 2017 and to increase contributions in both number and complexity." I guess/hope that means that Amazon will work to upstream their fixes into OpenJDK, so they become available for everybody.

If I didn't miss something, this implies that Amazon will merge Oracle's fixes from the main development line into the freely accessible #Corretto 11 code base. Even if they don't then work to include those merges in the OpenJDK 11 repo, others should be able to do that fairly easily. This makes a free, long-term supported, community-driven OpenJDK 11 all the more likely. Very cool!


Recent Posts

See All


bottom of page