Future of explicit class initialization APIs

[John Rose]

The ensureInitialized call is something that could be called
from Leyden-generated configuration activities that happen
before main.  Most such activities also involve some further
optimization, like dumping a Class object into the archive,
so in the end you can’t see ensureInitialized.  But it is
a logical link in the Leyden chain.  It’s easier to talk
about shifting (in the Leyden sense) the initialization
of a class if there is an actual reflective method that
can do the shifting of the initialization.

Also, there are, very rarely, cases where circular
initialization dependencies, among tightly coupled
classes, need to be organized properly.  (You can
get errors and deadlocks if you fail.)  One tactic
for organizing such initializers is for some
responsible party to “touch” the classes that need
to be initialized together, in the right order,
and in the same thread.  You can often do this
“touch” on a class by instantiating it or by reading
one of its statics.  But the only truly general way
to do such a “touch” is to call ensureInitialized.
After all, a particular class might not want you
to instantiate it, or it might not offer you a
static API point to access.  I mentioned this
comes up very rarely…

Do you have a reason NOT to allow this method?
Or are you just asking why we bothered to make
it public after all this time?  It’s part of the
Leyden toolkit.

— John