Devops Monk

Why Java 11 Matters

Java 8 was released in March 2014. It dominated enterprise Java for nearly a decade, but it misses a decade’s worth of language improvements, API modernisation, JVM advances, and security hardening. Java 11 (September 2018) is the first Long-Term Support release after Java 8, and it packages three releases of evolution into a single supported baseline.

For most teams the question is not whether to upgrade, but how. This series answers both what changed and how to adopt each feature in production code.

The 6-Month Release Cadence

Oracle changed the Java release model in 2017. Starting with Java 9, new versions ship every six months — March and September. Feature-complete releases arrive faster, but each non-LTS version receives only six months of update support.

LTS (Long-Term Support) means the OpenJDK project and distributions like Eclipse Temurin and Amazon Corretto commit to security and stability patches for multiple years — typically eight or more. For enterprise applications that cannot upgrade frequently, LTS is the only viable target.

Java 11 is the LTS release directly after Java 8. Teams upgrading today either land on Java 11 as a stepping stone, or leapfrog to Java 17 or 21. Either way, understanding Java 11 is essential because Java 11 introduced the Module System, removed Java EE APIs, and changed GC defaults — all of which affect every migration path.

What LTS Means in Practice

• Security patches: JVM and library vulnerabilities are fixed throughout the support window.
• No new features: Stability is prioritised; behaviour changes are minimal.
• Vendor commitments: Amazon Corretto, Eclipse Temurin, Azul Zulu, Microsoft Build all commit to Java 11 builds through at least 2026.
• Certification window: ISV software certifications last years — LTS aligns your runtime with your vendor’s support.

Java 9: The Big One (September 2017)

Java 9 was the most disruptive release in Java’s history. It delivered 22 significant JEPs, the largest single-release feature set since Java 5.

Core Language and JVM

APIs

JVM and GC

Tooling

Security

Java 10: API Polish (March 2018)

Java 10 was a shorter release but delivered the var keyword and several important JVM improvements.

Java 10 API additions (no JEP numbers, but notable):

• Optional.orElseThrow() — no-arg version, explicit about throwing
• List.copyOf(), Set.copyOf(), Map.copyOf() — defensive copy
• Collectors.toUnmodifiableList/Set/Map()
• Reader.transferTo(Writer), InputStream.transferTo(OutputStream)

Java 11: The LTS Payload (September 2018)

Java 11 standardised several incubating APIs and added the features that define modern Java.

Java 11 API additions (no JEP, but essential):

• String.isBlank(), .lines(), .strip(), .stripLeading(), .stripTrailing(), .repeat(n)
• Files.readString(Path), Files.writeString(Path, CharSequence)
• Optional.isEmpty()
• Path.of() — static factory replacing Paths.get()
• Predicate.not(Predicate) — static negation helper

Feature Impact Matrix

Which features matter most depends on what you are building:

The Migration Decision

Upgrade to Java 11 directly from Java 8?

Yes, in most cases. The key concerns:

1. JAXB/JAX-WS usage — Check with jdeps --multi-release 11 --class-path . myapp.jar. If your app uses javax.xml.bind.*, you must add the external Jakarta JAXB dependency.
2. Internal API access — Libraries using sun.misc.* or sun.reflect.* need updated versions. ASM 7.0+, Byte Buddy 1.9+, cglib 3.2.8+.
3. Build tool versions — Maven 3.6.1+, Gradle 4.7+, surefire plugin 2.22.0+.
4. JavaFX — If used, add the OpenJFX dependency separately.

Should you go straight to Java 17 or 21?

If you are starting a migration today, consider jumping to Java 17 (next LTS) or Java 21 (current LTS). Java 11 knowledge is still essential for understanding the migration path and for supporting teams on Java 11.

What’s Next

Next: Setting Up Java 11: JDK Options, Maven/Gradle, and IDE Configuration