Java 11 migration

[dmlloyd]

Description

It is necessary for a variety of reasons to move to Java 11 as a baseline platform requirement.

Analysis

Moving to Java 11 is a process that has to be taken in steps. The following requirements must be met:

• Minimize user disruption by providing a smooth migration timeline
• Define a definitive time frame for ending Java 8 support

Tasks

• Provide container images for Graal 19.3.0+ for Java 8 and Java 11
• Ensure that the existing test suite and TCK suite passes CI on Java 11 in JVM mode (update CI for Java 11 support): Add non-native JDK11 CI job #857
• Establish support for GraalVM 19.3.0+ in JDK 8 mode: Upgrade to GraalVM 19.3.0 / Java 8 edition #4218
• Introduce a deprecation warning when Java 8 is in use: Print deprecation warning when Java 8 is in use #7730
• Establish support for GraalVM 19.3.0+ in JDK 11 mode: Support GraalVM / native image builds using the GraalVM Java 11 build #5682
• Require GraalVM 19.3.1+
• Upstream native-image performance issue: Java 11 native builds are about 20% slower than Java8 #7080
• Ensure that the existing test suite and TCK suite passes CI on Java 11 in native mode (add CI support): #????
• Make JDK 11 the default on CI: Default our JVM builds and the native CI build to JDK 11 #7705
• Make JDK 11 the default container image: Make GraalVM Java 11 the default image #7774
• Backport JDK 11 to 1.3: Move 1.3 to Java 11 by default #8153
• Generate projects for JDK 11 by default: Generate projects for Java 11 by default #8151
• Update the plugin to require a minimum of JDK 11 / print an error for earlier versions, and remove Java 8 from CI: #????
• Update the build parents to require JDK 11
• Update the build parents to use 11 as release in compiler plugin configuration: #????
• Search for, and fix, TODO items for fixes and cleanups related to requiring Java 9 or 11: SO_REUSEPORT is not handled correctly #7493, #????
• Cleanup container images to deprecate java 8 image and switch back to single images.
• 🎉 🎈

[FroMage]

Is there any risk in requiring 11 wrt user libs? Are there any popular user lib that doesn't work when running on jdk > 8?

[dmlloyd]

User libs are an open-ended set, so the answer is (asymptotically) "yes" IMO. Hopefully at the point we start printing the deprecation warning, those kinds of issues will bubble up rapidly.

[dmlloyd]

/me apologizes to any experts on set theory :)

[cescoffier]

For the record, for the container images, I have duplicated all of them to have the java8 and java 11 ones. For example https://quay.io/repository/quarkus/ubi-quarkus-native-image?tab=tags

[dmlloyd]

@cescoffier do you want to add check items to cover the container image work? If so, please add them in the approximately correct place (chronologically). Thanks

[cescoffier]

@dmlloyd I have already done the container image work. So chronologically speaking it was first and checked :-)

[dmlloyd]

Great, that means we're already well along our way, let's add that check! :)

What about other tasks e.g. deprecating the 8 image, any future cleanup work after we drop 8, etc.?

[cescoffier]

@dmlloyd yes, cleanup and reverting to single image would be required once we decide to go full steam with java 11.

Edit: Tasks added to the list.

[maxandersen]

It is necessary for a variety of reasons to move to Java 11 as a baseline platform requirement.

Can we list those variety of reasonsas I'm sure we'll have many users still for whatever reasons (good and bad) stuck on java8. Would be great to have stated explicitly why java 11 beyound "it's the newest" for them to understand the advantages/needs.

[dmlloyd]

It is necessary for a variety of reasons to move to Java 11 as a baseline platform requirement.

Can we list those variety of reasonsas I'm sure we'll have many users still for whatever reasons (good and bad) stuck on java8. Would be great to have stated explicitly why java 11 beyound "it's the newest" for them to understand the advantages/needs.

In fact we never intended to support Java 8 at all. It was a requirement for native image generation only. The only reason that really matters is that Java 8 is extremely outdated and should really not be used for new projects, generally speaking.

[Sanne]

Is the checklist up to date?

We can probably close this "epic" and defer some of the minor polishing tasks?

[gsmet]

I think it mostly is, I updated it yesterday.

I prefer to have one issue that centralizes this personally so that we can be sure we don't forget anything.

[dmlloyd]

The main task - requiring 11 - doesn't even have an issue yet, so there's a bit more than "minor polishing" left... :-)

[Sanne]

I think it mostly is, I updated it yesterday.

I prefer to have one issue that centralizes this personally so that we can be sure we don't forget anything.

Fair enough, just checking this wasn't an abandoned issue.

The main task - requiring 11 - doesn't even have an issue yet, so there's a bit more than "minor polishing" left... :-)

Ok, but note that this issue is named "migration" not "requiring" - so I assumed we were good enough.

@dmlloyd when importing the Quarkus sources in IDEA, at least in my case it defaults to JDK11 and then it fails to compile because of:

import sun.misc.Signal;
import sun.misc.SignalHandler;

in io.quarkus.runtime.Application . Is that something on your radar?

[dmlloyd]

That's odd. Those classes are present in 11 (in the jdk.unsupported module) and I don't seem to have that problem, despite also using 11 as my default.

[sorin-costea]

Probably related to log4j2 multi-release feature, I get this warning:
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
I run under Java 11 but I think you'll see it from Java 9 on.

[jaikiran]

@dmlloyd when importing the Quarkus sources in IDEA, at least in my case it defaults to JDK11 and then it fails to compile because of:

import sun.misc.Signal;
import sun.misc.SignalHandler;

in io.quarkus.runtime.Application . Is that something on your radar?

Hello @Sanne, just saw your comment today. I remember running into this issue with IntelliJ IDEA too. Took me a while to understand that this is a IDE configuration issue. I had to "uncheck" the "Use '--release' option for cross-compilation (Java 9 and later)" under Preferences -> Build, Execution, Deployment -> Compiler -> Java Compiler to get the build working. That checkbox was (by default?) checked in my case which was causing this error.

[jaikiran]

Hello @sorin-costea,

Probably related to log4j2 multi-release feature, I get this warning:
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
I run under Java 11 but I think you'll see it from Java 9 on.

Can you please create a separate issue adding details about your Quarkus usage and when you see this message?

[MartinX3]

I this fixed with Quarkus 2.0?
In 1.13.x i still can't enable java 11 everywhere without getting an dying postgresql connection using kotlin.

[gsmet]

@MartinX3 Well, in this case better open a specific issue with a reproducer. Java 11 is supported since forever. This issue is about moving to Java 11 as the minimum version.

Thanks for the reminder anyway, this issue should be closed.

[MartinX3]

@gsmet
You added the 2.0 milestone
Does this mean I need to wait for 2.0? :)

Edit:
I created an issue ticket #17253