Why Dropping Java 8

This document explains what Quarkus would benefit by dropping Java 8.

Please fill it in as you find ideas, but keep it focused on the technical reasons: the APIs offered by Java 11 which make it compelling enough to drop Java 8 compatibility.

Not asking about the JVM runtime

Many have been keen to point out the benefits of running a Quarkus application on JVM11 (or later), however you can do so even if Quarkus maintains compatibility with Java 8.

Quarkus already is fully compatible and regularly tested with both Java 8 and Java 11 (as runtime).

We are specifically exploring reasons to require Java 11 as base, which would imply dropping compatibility with Java 8. So please focus on the SDK API.

Not asking about workarounds

In many cases it is possible to craft code to actually use minor improvements coming from the Java 11 (or later) SDKs, such as using multi-release jars or other tricks.

We’re aware that such options exist, but they come at a complexity cost:

• more complex implementation

• much harder to support

• harder to maintain

So the benefit of using such workarounds can only be justified on specific high-value cases, and more generally is dubious and we still want to explore the option of simply require Java 11 instead.

Good reasons to require Java 11

---

So far we didn’t identify many strong reasons. Please edit and add!

---

ServiceLoader API

The serviceLoader API often requires a different use in JDK11. It’s a minor thing but it’s a recurring pain, and enforcing Java 8 compatibility on all libraries of our platform extends this pain to all, and yet they can’t use a shared solution.

More efficient Collection

All new helpers such as Set.of(..) are a small improvement, but collections are used very extensively across all libraries. Such small benefits supposedly should add up.

Improved Stream helpers

I don’t remember the details, but it seems to be another regular "would be far nicer if we had Java11".

Concurrency

The java.util.concurrent.* tools have had many improvements which are of high interest to people writing highly efficient and highly performant code. Sadly I don’t know of a specific single case which makes a strong example [please edit?], and as often the case it seems we all prefer to use the slightly less efficient alternatives rather than getting in compatibility troubles. Again, such small paper cuts will add up and we’re holding back all libraries in the platform.

Classpath cleanup

With some modules being removed from the JDK in Java 11 (e.g. javax.xml.bind and javax.annotation) it leads to complex puzzles in dependency tree management, including occasionally dangerous duplications.

We all strife to make reasonable defaults, but dependency management isn’t currently able to deal on a per-platform dependency switch.