Use new RuntimeResourceSupport public API with GraalVM >= 22.3

[zakkak]

Also:

• Drop support for "legacy" (pre 21.1) localization feature as the minimum supported GraalVM version is 21.3
• Wrap trueBlock and falseBlock invocations in try-with-resources blocks

Relates to #25943

[quarkus-bot]

Failing Jobs - Building 85da3b5

Status	Name	Step	Failures	Logs	Raw logs
⌛	Gradle Tests - JDK 11	Set up JDK 11	⚠️ Check →	Logs	Raw logs
✔️	Gradle Tests - JDK 11 Windows

[jerboaa]

@zakkak I thought the public API is org.graalvm.nativeimage.hosted.RuntimeResourceAccess?

[zakkak]

To my understanding they are both public APIs that will be shipped in graal-sdk.

org.graalvm.nativeimage.hosted.RuntimeResourceAccess is part of the org.graalvm.nativeimage.hosted package and org.graalvm.nativeimage.impl.RuntimeResourceSupport is part of the org.graalvm.nativeimage package which are both included in graal-sdk.

The reason I went with RuntimeResourceSupport instead of RuntimeResourceAccess is that the former doesn't require to specify a module for the resources, and in Quarkus we are not using modules.

[jerboaa]

OK. When I see impl in an API class it raises a red flag to me. While it's true RuntimeResourceSupport doesn't require a module, we should get away with ClassLoader.getSystemClassLoader().getUnnamedModule() and use the RuntimeResourceAccess. In fact, RuntimeResourceAccess uses RuntimeResourceSupport which supports the idea that using the former will be a more robust solution. Also, you don't need to do the ImageSingleton handling yourself and it's in line with what we do in #27690. Your mileage may vary.

[zakkak]

The tough part is not about getting the unnamed module but getting the named module for JDK classes, e.g.

quarkus/core/deployment/src/main/java/io/quarkus/deployment/steps/ResourceBundleStep.java

Line 15 in 1f87a53

return new NativeImageResourceBundleBuildItem("sun.security.util.Resources");

Suggestions are welcome :)

[jerboaa]

sun.security.util.Resources is part of java.base so how about? int.class.getModule() The correct way is to use Foo.class.getModule() of course, but you might have a chicken/egg problem.

[zakkak]

This is just an example, there are more such cases and while getting the module might not be that hard what makes it hard is the fact that we need to get the module in the generated native-image Feature. So to make use of the RuntimeResourceAccess we need to:

1. Extend NativeImageResourceBundleBuildItem to contain information about the module
2. Generate the necessary code, using gizmo, to programmatically get that module and pass it to RuntimeResourceAccess in the generated native-image Feature.

Since RuntimeResourceSupport appears to be public API I don't see the need to do the above which will make the corresponding code even more complex.

As an alternative I believe that if we really don't want to use RuntimeResourceSupport we should suggest the augmentation of RuntimeResourceAccess to support registering resources without the module name.

[zakkak]

Apparently, I was wrong. org.graalvm.nativeimage.impl is indeed not supposed to be public API. But we already open it in

quarkus/core/deployment/src/main/java/io/quarkus/deployment/steps/NativeImageFeatureStep.java

Lines 130 to 132 in 92fba0a

	// required in order to access org.graalvm.nativeimage.impl.RuntimeSerializationSupport and org.graalvm.nativeimage.impl.ConfigurationCondition
	features.produce(
	new JPMSExportBuildItem("org.graalvm.sdk", "org.graalvm.nativeimage.impl", GraalVM.Version.VERSION_22_1_0));

which led me to thinking it's accessible by default.

I will need to prepare a follow up fix for this. Thanks for questioning this and making have another look @jerboaa!

[jerboaa]

@zakkak Thanks for coming back to this! I was meaning to come back to this discussion, but it dropped on the floor (for me). Yes, we should revisit this. IMHO, there might be latent bugs by not passing in Modules resources belong to.

[zakkak]

WIP PR taking care of the above: #28093