Upgrading 2.1.0.Final -> 2.7.0.Final native image generation fails (AWS Random/SplittableRandom)

[zeppelinux]

Hi All,

I'm having problem with upgrading my little service to the recent Quarkus 2.7.0.Final version from 2.1.0.Final. Here is the service code/reproducer: https://github.com/zeppelinux/quarked-ddns
It fails on java.util.Random. I tried to use the --initialize-at-run-time for different classes with no success.

Error: Unsupported features in 2 methods
Detailed message:
Error: Detected an instance of Random/SplittableRandom class in the image heap. Instances created during image generation have cached seed values and don't behave as expected.  To see how this object got instantiated use --trace-object-instantiation=java.util.Random. The object was probably created by a class initializer and is reachable from a static field. You can request class initialization at image runtime by using the option --initialize-at-run-time=<class-name>. Or you can write your own initialization methods and call them explicitly from your main entry point.
Trace: Object was reached by
reading field com.amazonaws.retry.PredefinedBackoffStrategies$EqualJitterBackoffStrategy.random of
constant com.amazonaws.retry.PredefinedBackoffStrategies$EqualJitterBackoffStrategy@8ef3c50 reached by
reading field com.amazonaws.retry.PredefinedBackoffStrategies$SDKDefaultBackoffStrategy.equalJitterBackoffStrategy of
constant com.amazonaws.retry.PredefinedBackoffStrategies$SDKDefaultBackoffStrategy@39b9ef62 reached by
reading field com.amazonaws.retry.RetryPolicy.backoffStrategy of
constant com.amazonaws.retry.RetryPolicy@4191932e reached by
scanning method com.amazonaws.ClientConfiguration.<init>(ClientConfiguration.java:154)
Call path from entry point to com.amazonaws.ClientConfiguration.<init>(ClientConfiguration):
at com.amazonaws.ClientConfiguration.<init>(ClientConfiguration.java:377)
at com.amazonaws.client.builder.AwsClientBuilder.resolveClientConfiguration(AwsClientBuilder.java:169)
at com.amazonaws.client.builder.AwsClientBuilder.access$000(AwsClientBuilder.java:54)
at com.amazonaws.client.builder.AwsClientBuilder$SyncBuilderParams.<init>(AwsClientBuilder.java:505)
at com.amazonaws.client.builder.AwsClientBuilder.getSyncClientParams(AwsClientBuilder.java:441)
at com.amazonaws.client.builder.AwsSyncClientBuilder.build(AwsSyncClientBuilder.java:46)
at com.diligesoft.qddns.AppProducer.getAmazonClient(AppProducer.java:28)
at com.diligesoft.qddns.AppProducer_ProducerMethod_getAmazonClient_a95f828a93199fb3e7c74618f70747de578a7545_Bean.create(Unknown Source)
at com.diligesoft.qddns.AppProducer_ProducerMethod_getAmazonClient_a95f828a93199fb3e7c74618f70747de578a7545_Bean.create(Unknown Source)
at io.quarkus.arc.impl.AbstractSharedContext.createInstanceHandle(AbstractSharedContext.java:101)
at io.quarkus.arc.impl.AbstractSharedContext$1.get(AbstractSharedContext.java:29)
at io.quarkus.arc.impl.AbstractSharedContext$1.get(AbstractSharedContext.java:26)
at com.oracle.svm.core.jdk.SystemPropertiesSupport.initializeLazyValue(SystemPropertiesSupport.java:216)
at com.oracle.svm.core.jdk.SystemPropertiesSupport.getProperty(SystemPropertiesSupport.java:169)
at com.oracle.svm.core.jdk.Target_java_lang_System.getProperty(JavaLangSubstitutions.java:287)
at com.oracle.svm.jni.JNIJavaCallWrappers.jniInvoke_VA_LIST_System_getProperty_deeeaa72a006d330408a3b7d002c7533e108bc28(generated:0)

Most likely it exposes some problem with my code that worked before because GraalVM was not so strict (or whatever), but I'm not sure how to make it work again. I.e. what is the proper way to initialize Amazon ClientConfiguration in this case?

[sberyozkin]

@zeppelinux Hi, indeed, GraalVM has become stricter with statically initialized SecureRandom, in Quarkus a runtime re-initialization is requested for such cases, I'm not sure though how to request it outside of Quarkus, @zakkak, can you advise please ?

[sberyozkin]

@zeppelinux Right, that is what I meant to say. So when dealing with it inside of Quarkus itself we use RuntimeReinitializedBuildItem and as far as I understand it leads to a substrate API call, as I don't see a native arg like --runtime-reinitialize. I'm pretty sure you can find the answer in GraalVM forums, I vaguely recall seeing something related to it, you may need to register a feature requesting the reinitialization or something like that, it is not really a Quarkus specific issue

[zakkak]

@zeppelinux you can find an example of a feature registering some classes for re-initialization in oracle/graal#2800 (comment) hopefully it will get you moving :)

[bkzoller]

I'm not sure if this will help native compilation, but your route53 dependency is quite old. The latest AWS SDK is version 2 and this is the latest route53 library, which is likely to work better with the Quarkus AWS dependencies.

You can pass command-line arguments to GraalVM using application.properties or application.yaml.

quarkus:
  native:
    container-runtime: docker
    additional-build-args: --trace-class-initialization=com.amazonaws.retry.PredefinedBackoffStrategies,\
      --initialize-at-run-time=com.amazonaws.retry.PredefinedBackoffStrategies

[zakkak]

Just a note that --initialize-at-run-time is not the same as re-initializing at runtime. The former will prohibit the class from being initialized at build time (which might still fix the issue or lead to more issues since instances of that class won't be able to be embed in the native image heap) while the latter will allow it to be initialized at build time and will reinit it at run-time.

[zeppelinux]

@bkzoller @sberyozkin @zakkak I ported my service to use the new AWS SDK version 2 and it's all good now. Thanks Guys!