[GR-51416] Registering a class as initialize-at-build-time should immediately trigger initialization.

[graalvmbot]

The new "allow all hosted usage" class initialization policy behaved differently than the old one: when registering a class (not a package) with initializeAtBuildTime, then the class was not immediately initialized in the image generator. Initially, I thought that is a good idea because then unnecessary side effects of the class initializer are avoided. But the old behavior is better for many reasons:

• We need a way to break class initialization deadlocks and cycles, and "initialize at build time" for a single class it the easiest way of doing that.
• We want a deterministic behavior: when a class is initialized at build time, the side effects of the class initializer should be visible regardless whether the class is actually reachable in the application.

I plan to merge that also into the 24.0 release where the new strategy is the default for the first time.

[jerboaa]

@christianwimmer Are you planning to backport this to 24.0? We see this issue on JDK 22 based builds too. See for example:
graalvm#644 (comment) and
https://github.com/graalvm/mandrel/actions/runs/7591232948/job/20679453988#step:12:2252

[christianwimmer]

Are you planning to backport this to 24.0?

Yes, it is right now in the merge queue for the 24.0 branch.

[jerboaa]

Thanks for the heads up!

[jerboaa]

@zapster @christianwimmer Unfortunately this didn't seem to fix the issue we were seeing in Quarkus native integration tests. See #8075 (comment) FYI.

[zakkak]

FTR this was backported to 24.0 with b99a9f3