🖥 Java постепенно закручивает гайки вокруг мутации final-полей через reflection.
В JDK 26 появятся предупреждения, если код меняет final-поля через Reflection API. Это часть движения к тому, чтобы final снова означал реальную неизменяемость, а не «почти immutable, пока кто-то не сделал setAccessible(true)».
Проблема старая: фреймворки, сериализация, DI и cloning часто создавали «пустой» объект, а потом дописывали поля напрямую. Для final это ломает саму идею конструктора, инвариантов и безопасной инициализации.
Что предлагает Java-команда вместо этого:
- использовать constructor injection вместо field injection
- восстанавливать объекты через конструкторы или static factory
- для сериализации чаще выбирать records
- применять serialization proxy / readResolve
- не полагаться на порядок полей в reflection
- не превращать private-поля в скрытый публичный протокол
- менять final через reflection только как крайний случай
Самый практичный вывод для Java-разработчиков: если ваша библиотека, фреймворк или приложение «оживляет» объекты через reflection, пора проверить этот код заранее. Сегодня это может быть просто warning, завтра - реальное ограничение.
https://inside.java/2026/04/27/avoiding-final-field-mutation/
#java
