From Final to Immutable: The not-so-final word on `final`
summary
Explains concrete changes: a command-line permission and eventual errors stop reflective writes to final fields so JVM can treat them as immutable; introduces strict final fields (requires early initialization via the flexible-constructor-body change in Java 25) so fields are observable in only one state; and ships a Stable Values (Preview) API that provides atomic at-most-once lazy initialization and a higher-level stable value API (caching supplier, stable collections) that combines laziness with constant-folding optimizations. Benchmarks show records/strict finals fold where plain finals do not.
AI-written summary · about
chapters (7)
- 0:00The role of immutability
- 3:44Benefits of final fields
- 6:42Limitations of final fields
- 14:30Strict final fields
- 19:32Lazy initialization challenges
- 25:45Stable values API
- 34:33Conclusion and Q&A
related talks
37mTruly Final Fields
44mFinal - In Search of Performance
44mA New Model for Java Object Initialization
50mBetter Tools for Immutable Data
01h 11mModern Java: This is not your father's Java anymore
36mJava Language Futures - Mid 2020 Edition
18mFinalizers - The not so good, the bad and the ugly
52mJava Language Futures