JEP 539: Strict Field Initialization in the JVM moved to preview
za3faran
59 points
17 comments
July 02, 2026
Related Discussions
Found 5 related stories in 603.0ms across 14,015 title embeddings via pgvector HNSW
- The J Programming Language (2014) tosh · 14 pts · June 07, 2026 · 50% similar
- Java 26 Release Notes Alupis · 13 pts · March 17, 2026 · 47% similar
- Java 27: What's New? loicmathieu · 52 pts · July 10, 2026 · 46% similar
- LuaJIT 3.0 proposed syntax extensions phreddypharkus · 115 pts · June 25, 2026 · 46% similar
- Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28 philonoist · 567 pts · June 19, 2026 · 45% similar
Discussion Highlights (4 comments)
cogman10
This is a great change that will undoubtedly cause a lot of headaches. There's a number of libraries (particularly around serialization/marshaling) which will end up mutating `final` fields. In fact, this is a trick I've pulled once or twice in my own code for "reasons" (generally needing to modify behavior of a library because it was deficient). I suspect this will be one of those things that ends up requiring java devs everywhere to bump up the versions of the libraries they use.
rvcdbn
oracle planning a new jvm language? have we ever seen a feature like this that is explicitly not usable from Java?
joe_mwangi
Also, this will be used for future null-restricted types.
exabrial
This a much needed change. Glad to see it! Might be some headaches in the short term, but thats ok.