<div dir="ltr">Continuing on the Class init progression discussion.... <div><br></div><div>Why don't we put every static field in its own class?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>It gives each static field a clear initialization point where we can more easily tell what caused a particular static to be initialized.</div><div><br></div><div>It makes it easier to determine the true dependency graph between static fields rather than today's "soupy" model.</div><div><br></div><div>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? </div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>--Dan</div><div><br><div>[0] <a href="http://cr.openjdk.java.net/~heidinga/leyden/ClassInitPlan.pdf">http://cr.openjdk.java.net/~heidinga/leyden/ClassInitPlan.pdf</a></div><div></div><div><br></div></div></div>