Replace proxy runtime init code with "-H:+UseNewExperimentalClassInit…

[shumonsharif]

…ialization"

@ppalaga I'm wondering if the -H:+UseNewExperimentalClassInitialization flag is a viable alternative to the Proxy runtime initialization workarounds we put in place. This approach also resolves all the cyclic issues identified in #860 and #916 .

EDIT: Looking closer through all the previous notes on Proxy runtime init, I just stumbled upon #580 (comment) where oracle/graal#4684 was already referenced. I guess I could've saved a couple hours of digging if I had read all of the notes carefully!!

I'm curious why you didn't go with this option, as it seems to be only a matter of time before this becomes the new default in Graal?

[dufoli]

What is the stage of this graal feature ?

[shumonsharif]

Hi @dufoli I'm not quite sure which stage this feature is in, or any specific timelines around it. Pretty much the only info I have is in the referenced graal issue.

It seems like a far simpler solution (even though the flag is experimental) to address the very unique edge case of proxy runtime initialization. I feel like we may be able to live with this flag until it becomes the Graal default - only because the list of extensions quarkus-cxf is currently incompatible with due to the cycle issues, seems to keep growing.

[shumonsharif]

@ppalaga @dufoli
FYSA: https://groups.google.com/g/quarkus-dev/c/vGDPhln4qFw/m/Q02_FOASCAAJ

[dufoli]

So I think it is a good signal to migrate on it right now and reduce loop bug

[andre-s-sousa]

Hey guys, any idea when this may get merged and released?
Sadly the loop bug is causing quite some issues that I have no solution for

[dufoli]

@ppalaga what do you think about it ?

[ppalaga]

I finally found time to start looking into this. Sorry for the delay.

[ppalaga]

I have commented in #860 (comment) and in accordance with that I am for closing the current PR in favor of #963