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.