Java plan prepares to restrict final field mutation

A JDK Enhancement Proposal (JEP) to prepare to make final mean final in Java would issue warnings about uses of deep reflection to mutate final fields. The warnings would prepare Java developers for a future release that ensures integrity by default by restricting final field mutation, making Java safer and potentially faster.

The proposal was created in early-February and updated on March 31. A key goal of the plan is  to prepare the Java ecosystem for a future release that by default disallows mutation of final fields by deep reflection. As of that release, developers will have to explicitly enable the capability to mutate final fields at startup. Other goals include aligning final fields in normal classes with components of record classes, which cannot be mutated by deep reflection, and allowing serialization libraries to continue working with Serializable classes, even those with final fields. There is no plan to deprecate or remove any part of the Java Platform API or prevent mutation of final fields by serialization libraries during deserialization. The JEP currently does not list a version of Java that would get the final-means-final capability.

Detailing motivation for the plan, the proposal says Java developers rely on final fields to represent immutable state. The expectation that a final field cannot be reassigned, whether deliberately or accidentally, is often crucial when developers reason about correctness. But the expectation that a final field cannot be reassigned is false. The Java platform provides APIs that allow reassignment of final fields at any time by any code in the program, thus undermining reasoning about correctness and invalidating important optimizations. Thus a final field is as mutable as a non-final field.

Although relatively little code mutates final fields, the existence of APIs for doing this makes it impossible for developers or the JVM to trust the value of any final field. This compromises safety and performance of all programs, according to the proposal. Plans call for enforcing the immutability of final fields so that code cannot use deep reflection to reassign them at will. One special case—serialization libraries needing to mutate final fields during deserialization—will be supported via a limited-purpose API.