right, so this is turning out to be a mess - current approach is not sufficient and we basically restore more of 31f1ed6 to get proxy class initialization ~ in 9.4.6.0

first, the #8208 causes the proxy class to be assigned multiple times (it's just that the warnings do not surface in CI much and JRuby also has checks to ignore them due potential concurrent loading e.g. #8250)

second, I am not sure the fix for #8156 is legit, internally both proxy classes will be present it's just a question which one will "surface" first.

@kares The main problem here is just the proxy classes getting into the constant table, right? Can't we just avoid that aspect and leave the rest the way it is? Store it some other way?

the thing I do not like is we're now constantly doing the checking of the proxy constant on every getProxyClass path, previously the setting of the constant only happened on paths that mostly executed once (e.g. on method_missing).

the current way I could think of (wout bigger refactoring) would be to revert 31f1ed6 and try implementing it without changing getProxyClass... unless you have a better idea I would try that (current state of PR here is not the way to go).

unless you have a better idea I would try that

@kares Yeah go ahead and try something else. I was hopeful that that simple fix would be safe, but it seems there's this side effect we definitely don't want.

The original issue was that a random generated version of a class was added into that global namespace, masking the one that lives in JRuby's classloader hierarchy. If we can solve that in a more targeted way (comparing classloader hierarchy? some fast way to check if this class was loaded from our classloaders?) I'd be thrilled.

second attempt at #8368