Java 11 LTS: Why Now Is the Time to Upgrade

Just over a month ago, on September 25th, Oracle released Java 11. At first glance, it sounds like an ordinary release -- the next number in line after Java 9 and 10. But Java 11 is anything but ordinary: it is the first Long-Term-Support release since Java 8 and thus the logical migration path for the majority of all Java projects. For teams that deliberately skipped Java 9 and 10, the time has come to seriously consider the upgrade.

The New Release Cadence: What Has Changed?

With Java 9, Oracle fundamentally changed its release strategy. Instead of publishing a major release with dozens of features every few years, a new Java version now appears every six months. Java 9 arrived in September 2017, Java 10 in March 2018, Java 11 in September 2018 -- the cadence is strict.

The crucial point: not every version receives long-term support. Java 9 and 10 were so-called feature releases with only six months of support. Once the successor version appeared, there were no more security updates. For production systems, that was too short-lived -- understandably, many teams therefore stayed on Java 8.

Java 11 is now the first LTS version under the new model. Oracle will provide updates for it until at least September 2023, and other vendors like AdoptOpenJDK or Red Hat even beyond that. The next LTS release is expected to be Java 17 in September 2021. So if you need stability, Java 11 provides a solid foundation for the years ahead.

Licensing: OpenJDK Becomes the Standard

In addition to the release cadence, Oracle has also changed the licensing -- and that is causing uncertainty. In short: starting with Java 11, the Oracle JDK is no longer free for production use. Anyone who wants to use the Oracle JDK with commercial support needs a paid subscription.

The good news: OpenJDK is functionally identical and remains free. Oracle itself has eliminated the remaining differences between Oracle JDK and OpenJDK with Java 11. In practice, this means: OpenJDK is now the standard distribution for most teams. If you have been downloading the Oracle JDK, you should switch to OpenJDK builds -- for example from AdoptOpenJDK, Amazon Corretto, or your distribution's own packages.

The Most Important Features from Java 9 to 11

If you migrate directly from Java 8 to 11, you get three versions' worth of new features at once. Beyond the module system (JPMS), which we covered in detail in an earlier article, the following features are particularly relevant in practice.

Local Type Inference with var (Java 10)

With the var keyword, the compiler can infer the type of a local variable from the initialization expression. This reduces boilerplate, especially with generic types:

// before
Map<String, List<Customer>> customersByCity = getCustomersByCity();
HttpURLConnection connection = (HttpURLConnection) url.openConnection();

// after
var customersByCity = getCustomersByCity();
var connection = (HttpURLConnection) url.openConnection();

Important: var is not a dynamic type like in JavaScript. The variable is still strongly typed -- the compiler simply determines the type automatically. Its use is limited to local variables with initialization; var is not permitted for fields, parameters, or return types.

Our tip: use var where the type is obvious from context. With var result = service.process(input), readability suffers because it's not clear what type result is.

New String Methods (Java 11)

Strings get some long-overdue methods in Java 11 that were previously only available through external libraries like Apache Commons Lang:

// Whitespace check -- better than trim().isEmpty()
"   ".isBlank();           // true
"hello".isBlank();         // false

// Unicode-aware trimming
"  hello  ".strip();       // "hello"
"  hello  ".stripLeading();// "hello  "
"  hello  ".stripTrailing();// "  hello"

// Processing multiline strings
"line1\nline2\nline3".lines().count();  // 3

// Repeating a string
"ab".repeat(3);            // "ababab"

The strip() methods are explicitly Unicode-aware and thus preferable to trim(), which only removes ASCII whitespace.

Collection Factory Methods (Java 9)

Immutable collections can be created concisely since Java 9, without having to resort to Collections.unmodifiableList() or Guava:

var names = List.of("Anna", "Ben", "Clara");
var ids = Set.of(1, 2, 3);
var config = Map.of(
    "host", "localhost",
    "port", "8080"
);

The resulting collections are immutable -- any attempt to add or remove elements throws an UnsupportedOperationException. This is deliberate API design and promotes defensive programming.

HTTP Client (Java 11)

The new HTTP Client, which debuted as an incubator module in Java 9, has arrived in Java 11 as a permanent part of java.net.http. It replaces the venerable HttpURLConnection and supports HTTP/2, WebSockets, and asynchronous calls:

var client = HttpClient.newHttpClient();
var request = HttpRequest.newBuilder()
        .uri(URI.create("https://api.example.com/users"))
        .header("Accept", "application/json")
        .GET()
        .build();

var response = client.send(request, HttpResponse.BodyHandlers.ofString());
System.out.println(response.statusCode());
System.out.println(response.body());

For many projects that previously included Apache HttpClient or OkHttp solely for simple REST calls, the new client can mean one fewer dependency.

Single-File Execution (Java 11)

Java files containing a single class can be executed directly from Java 11 onwards, without prior compilation:

java HelloWorld.java

For production code this is irrelevant, but for scripting, quick prototypes, and teaching it is a welcome simplification.

Migration Pitfalls: What Breaks During the Upgrade

Migrating from Java 8 to 11 is technically more demanding than previous version changes. Two areas typically cause the most problems.

Removed Java EE modules: Java 11 removes several modules that were marked as deprecated since Java 9. Most commonly affected: JAXB (javax.xml.bind), JAX-WS (javax.xml.ws), JTA (javax.transaction), and the Common Annotations (javax.annotation). If you use JAXB for XML marshalling or @PostConstruct annotations, you need to include the corresponding libraries as explicit dependencies -- for example jakarta.xml.bind-api and an implementation like org.glassfish.jaxb.

JavaFX is no longer included in the JDK. If you build JavaFX applications, you must include it as a separate SDK. For backend developers this is usually irrelevant, but it can affect build scripts that assume a complete JDK installation.

Our Recommendation

For teams still on Java 8, Java 11 is the right time to migrate. The LTS support provides planning certainty, the ecosystem has stabilized significantly since Java 9, and most common frameworks -- Spring Boot 2.1, Hibernate 5.3, Jackson 2.9 -- run without issues on Java 11.

A pragmatic migration plan looks like this:

1. Set up OpenJDK 11 and update the build toolchain (Maven/Gradle compiler plugin, CI server)
2. Compile and run tests -- most errors will immediately show up as missing imports for JAXB and the like
3. Add removed modules as dependencies -- in most cases, three to four additional dependencies in the pom.xml or build.gradle will suffice
4. Check illegal-access warnings -- set --illegal-access=deny as a JVM flag and clean up any remaining reflection access to internal APIs
5. Introduce new features gradually -- use var, the new String methods, and collection factories in new code

At encircle360, we have already migrated our first services to Java 11. The biggest hurdle was the JAXB migration for a service with extensive XML processing -- but overall the effort was manageable and has already paid off through the more modern API and better performance of the new JVM.