A class per static field? Why or why not?

[Dan Heidinga]

Continuing on the Class init progression discussion....

Why don't we put every static field in its own class?

The obvious answer is that it's too much mental load for developers. But if
we put that aside for a moment, and assume that we have infinitely smart
developers, it might be useful to understand why we don't program like this
now.  Or what programming like this might actually look like.

Putting every static field in its own class trivially gives us lazy static
fields (sorry John, no new JEP required in this world) with each static
only being initialized when actually accessed.

It gives each static field a clear initialization point where we can more
easily tell what caused a particular static to be initialized.

It makes it easier to determine the true dependency graph between static
fields rather than today's "soupy" model.

It doesn't solve the "soupy" <clinit> problem as developers can still do
arbitrary things in the <clinit> but it does reduce the problem as it moves
a lot of code out of the common <clinit> as each static now has its own
<clinit>.  Does this make analysis more tractable?

In our investigation [0], we focused on the underlying JVM physics of
classes and looked at the memory use of this approach.  Which was estimated
to average out to under 1K per class.

What do other languages do with their equivalent of static state? Are there
different design points for expressing static state we should be
investigating to better enable shifting computation to different points in
time?

--Dan

[0] http://cr.openjdk.java.net/~heidinga/leyden/ClassInitPlan.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20221207/8f9ac362/attachment.htm>