Default to Java17-based builder-images for native executable generation

[zakkak]

This reverts commit e2771de and makes
the use of java17-based builder-images the default without taking into
account the JVM version used to build the project.

The motivation for this change is that the builder-image compiles
bytecode to binary files and in theory a Java17-based builder-image
should be able to compile Java bytecode generated by a Java11 compiler
and produce a native executable that behaves the same as a native
executable generated by a Java11-based builder-image.

A key difference between a native executable generated by a Java11-based
builder-image and a native executable generated by a Java17-based
builder-image is that they include (embedded in the native executable)
different implementations of the JDK standard libraries. In theory this
should not be an issue, given that Java is backwards compatible and the
Java11 APIs of the standard libraries should still be implemented and
respected in Java17.

This change will allow us to test this hypothesis in practice as well :)
If things work as expected then we can drop Java11-based builder-images
and only generate/maintain Java17-based ones.

[jerboaa]

Question is are there JDK version specific hooks being done in Quarkus and relevant extensions at the Java/Bytecode level based on the JVM version in use. If so, would that effect say, -Dquarkus.package.type=native-sources builds? Could we binary compare a native-sources build with JDK 11 and JDK 17 and see if there are differences?

[Sanne]

@jerboaa it's a good question but no I'm not aware of us deciding to generate different code based on the configured target.

Of course this is a bit dangerous still as JDK 11 and 17 are not the same - in particular it's also a bit stricter in some cases with module visibilities.

But since in theory we're supporting JDK 17 already and aren't aware of specific problems, I'm +1 to make the switch not least to encourage becoming aware of any particular issue - and since JDK17 is the future, we need to fix any such issue anyway.

[quarkus-bot]

Failing Jobs - Building 7999502

Status	Name	Step	Failures	Logs	Raw logs
✖	Gradle Tests - JDK 11 Windows	Build	Failures	Logs	Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ Gradle Tests - JDK 11 Windows #

- Failing: integration-tests/gradle 

📦 integration-tests/gradle

✖ io.quarkus.gradle.devmode.CompositeBuildWithDependenciesDevModeTest.main line 24 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference, java.util.concurrent.atomic.AtomicReferencejava.lang.String, java.lang.Stringboolean was not fulfilled within 1 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

[Sanne]

Nice cleanup! Thanks :)