Bump GraalVM and Mandrel version to 22.1

[zakkak]

Closes #25199

Openning as Draft till CI runs on my fork

[gsmet]

The svm thing is a bit concerning but let's get this in.

Does it make sense to push the envelope a bit and backport it to 2.9?

[jorsol]

The svm thing is a bit concerning but let's get this in.

Does it make sense to push the envelope a bit and backport it to 2.9?

Yes, it make sense to backport it to 2.9, GraalVM 22.0.0.2 might be affected by the Java ECDSA Signature Vulnerability so if CI pass with all the battery of tests that Quarkus has, then it's a sane choice.

We are already using GraalVM 22.1 with Quarkus 2.8.2 and it compiles fine for our use case (through we haven't extensively tested it yet) and having an official support by Quarkus it will give us more confidence to use it.

Also, the svm thing is annoying but there are two dependencies used, the org.graalvm.nativeimage:svm which Oracle don't want to release the artifact for newer versions, and org.graalvm.sdk:graal-sdk which is still being updated, so here I would say that at least the graal-sdk must be updated since it's also affected by a security issue: https://security.snyk.io/vuln/SNYK-JAVA-ORGGRAALVMSDK-2767964

[gsmet]

That makes sense: @zakkak we should probably have a specific version for svm and keep updating the SDK. Providing it works, which might become a problem at some point unfortunately.

[zakkak]

That makes sense: @zakkak we should probably have a specific version for svm and keep updating the SDK. Providing it works, which might become a problem at some point unfortunately.

ACK, that makes sense.

For some context though let me clarify that the only reason Quarkus depends on org.graalvm.nativeimage:svm and org.graalvm.sdk:graal-sdk is for javac to not complain when compiling code referencing the corresponding APIs, the actual implementations of the APIs are only accessed during native image build in which case it uses the implementations provided by the corresponding GraalVM or Mandrel. As a result no matter the version we define in the pom.xml files the implementation that will be used depends on the GraalVM or Mandrel version actually being used when building the native image, which also allows us to be able to build Quarkus applications with different GraalVM/Mandrel applications without needing to change the graal-sdk.version property.

Update: I forgot to also mention that as a result using an older graal-sdk during non-native compilation doesn't expose Quarkus applications to https://security.snyk.io/vuln/SNYK-JAVA-ORGGRAALVMSDK-2767964 (which AFAIK only affects the enterprise edition of GraalVM, see https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21449)

[zakkak]

Does it make sense to push the envelope a bit and backport it to 2.9?

I have been testing main with 22.1 for quite some time now. That testing however only included running the integration tests included in the repository, so there might be issues with external dependencies that have not been tested.

I am +0 on it.