That class App calling Log.currentPID() in its final static field initializer? It just read 0 for appID because the Log class initialized first, grabbing the uninitialized default. That discrepancy—App[96052] vs App[0]—is exactly the class of bugs JEP 539 aims to kill at the VM level.
Dan Smith's proposal, now a preview feature in the JVM, introduces the concept of strictly-initialized fields. Opt-in on a per-field basis (static or instance), these fields must be written before they can be read. Non-strict fields keep the old behavior (default zero/null if nothing writes them). Strict fields never expose defaults, and if marked final, they guarantee every read sees the same value—no more racing final field reads during initialization.
Why Default Values Are a Safety Net with Holes
Default values (0, false, null) are Java's answer to uninitialized memory. They prevent an outright crash, but they let bugs metastasize. A method reads null from a field, passes it through five layers, then triggers a NullPointerException far from the real source. JDK 14 improved NPE messages to point to the offending line, but that still doesn't tell you the field was never explicitly assigned. Strict field initialization cuts the root: the field can't be read at all until someone writes to it.
The Circular Initialization Trap
The JEP's own example shows how subtle this gets. App.appID is a final static long initialized by calling Log.currentPID(). That call triggers Log class initialization, which in its own static initializer reads App.appID—getting 0 because App hasn't finished initializing. The prefix string now embeds 0. Later, App.appID gets the real PID (96052), but the damage is done. Different parts of the program see different IDs. This isn't theoretical; I've seen production systems where config values flip depending on class loading order.
Strict fields don't care about order. If a strictly-initialized field hasn't been written, the JVM throws an error at the point of the read—loud, early, and local. The compiler (e.g., javac for a hypothetical Java-level feature) decides which fields to mark strict. For JVM language designers, this is a new tool in the bytecode emission toolkit.
What This Means for JVM Languages
JEP 539 is not a Java language change—it's a VM facility. Kotlin, Scala, Clojure, or any JVM-hosted language can now emit strict field flags in their class files. The authors get stronger integrity guarantees without rewriting their type systems. For Java itself, this JEP is a preview; don't expect strict keywords in Java source until a future JEP. But the bytecode infrastructure is there, and that's the hard part.
Strict initialization raises the bar: you can't accidentally declare a field and forget to initialize it, hoping the VM will paper over it with a default. If your language's semantics demand default values, don't opt in. If you want to catch initialization bugs at class loading instead of during a null pointer chase three hours later, strict fields are your answer.
One preview JEP doesn't rewrite every JVM app overnight, but the direction is clear: the JVM is finally giving language designers a way to eliminate that entire class of initialization bugs.
Source: JEP 539: Strict Field Initialization in the JVM moved to preview
Domain: openjdk.org
Comments load interactively on the live page.