<div dir="ltr">Thanks for the elaboration, John!<div>The impression that ensureInitialized is dangerous as a user-accessible API is from the 2023 JVMLS talk about Class Loading, where side-effects and inconsistent Class-Loading occurrences hamper optimization efforts. </div><div><br></div><div>There's definitely no reason to remove this API. Users can just fabricate a no-op static void "init" to load their own classes if they need, or to use Class.forName("name", true, loader). I was just wondering if the addition of a MH barrier version (so we can create a barrier MH that can elide the barrier in LambdaForm after first invocation, like the static accessor LambdaForms) is plausible within the context of Leyden.</div><div><br></div><div>So, does such a init-barrier-for-a-MH API in 8246634 work fine with Leyden's condensation and delayed initialization, and is it still a worthy RFE after 3 years of Java's evolution?</div><div><br></div><div>Chen Liang</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 22, 2023 at 3:31 AM John Rose <<a href="mailto:john.r.rose@oracle.com">john.r.rose@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The ensureInitialized call is something that could be called<br>
from Leyden-generated configuration activities that happen<br>
before main.  Most such activities also involve some further<br>
optimization, like dumping a Class object into the archive,<br>
so in the end you can’t see ensureInitialized.  But it is<br>
a logical link in the Leyden chain.  It’s easier to talk<br>
about shifting (in the Leyden sense) the initialization<br>
of a class if there is an actual reflective method that<br>
can do the shifting of the initialization.<br>
<br>
Also, there are, very rarely, cases where circular<br>
initialization dependencies, among tightly coupled<br>
classes, need to be organized properly.  (You can<br>
get errors and deadlocks if you fail.)  One tactic<br>
for organizing such initializers is for some<br>
responsible party to “touch” the classes that need<br>
to be initialized together, in the right order,<br>
and in the same thread.  You can often do this<br>
“touch” on a class by instantiating it or by reading<br>
one of its statics.  But the only truly general way<br>
to do such a “touch” is to call ensureInitialized.<br>
After all, a particular class might not want you<br>
to instantiate it, or it might not offer you a<br>
static API point to access.  I mentioned this<br>
comes up very rarely…<br>
<br>
Do you have a reason NOT to allow this method?<br>
Or are you just asking why we bothered to make<br>
it public after all this time?  It’s part of the<br>
Leyden toolkit.<br>
<br>
— John<br>
</blockquote></div>