Foivos Zakkak
Foivos Zakkak
https://github.com/oracle/graal/commit/4880346c9d3491b7b367fcd1ca6bfc5c3fc3fa7f#diff-2f2b04e4347237de74c38065683de2f463234ce2e8e3e37b56bbc66cf2d2d068 enabled by default the ["new class initialization strategy that allows all classes to be used at image build time"](https://github.com/oracle/graal/pull/4684). As a result starting with Mandrel and GraalVM 23.1 Quarkus...
Well that took longer than expected... The conclusion is that the new class initialization **doesn't really affect Quarkus** since we explicitly set classes to be build time initialized and request...
According to https://github.com/oracle/graal/issues/5013#issuecomment-1944747803: > @zakkak with the new class initialization policy, RuntimeClassInitializationSupport#rerunInitialization is the same as initializeAtRunTime. > > With https://github.com/oracle/graal/pull/8323/files#diff-3c452e61cb9ddfbab251a9aa0a134b4c0be47a0ec39020eee896e97a3ef5e2f1R55 rerunInitialization will be deprecated and hard-code to initializeAtRunTime. That...
Please also consider what @turing85 suggested in https://github.com/nats-io/nats.java/issues/562#issuecomment-1460947435 about altering the source code to avoid the issue in the first place instead of trying to instruct GraalVM how to handle...
@YunaBraska looking at the error log in https://github.com/nats-io/nats.java/issues/562#issue-1050099148 it looks like this is being triggered when using Quarkus. Have you tried compiling the project to native outside of a Quarkus...
@YunaBraska it looks like this is actually already handled in https://github.com/quarkiverse/quarkus-reactive-messaging-nats-jetstream/blob/2bdcecf3e76b9125c39ca8041f8169342814d5d4/deployment/src/main/java/io/quarkiverse/reactive/messaging/nats/jetstream/deployment/ReactiveMesssagingNatsJetstreamProcessor.java#L44
Hi @vjovanov, does `--link-at-build-time` suffice to keep the old behavior? Perhaps it would be worth mentioning how to bring back the old behavior in the changelog and the deprecation message.
> @zakkak the previous behavior can be kept with -H:-ReportUnsupportedElementsAtRuntime Oh, it's just the API option being deprecated not the internal one. I see. > but I would not recommend...
Thanks for the info @vjovanov. FWIW doing a [quick search in the Quarkus repository](https://github.com/search?q=repo%3Aquarkusio%2Fquarkus%20%40delete&type=code) I see multiple uses of `@Delete`, which makes me believe that it might not be that...