👩‍💻 В Java хотят дать возможность запретить читать поле до того, как ему присвоили значение

Дело в том, что, когда создаётся объект, его поля сначала получают значения по умолчанию (null для ссылок, 0 для чисел, false для boolean) и только затем выполняется код инициализации.

По итогу на уровне JVM существует короткий промежуток времени, когда поле уже можно прочитать, хотя ему ещё не присвоили настоящее значение. Давайте рассмотрим вот такой пример:

class Parent {
    Parent() {
        // Вызов попадёт в переопределённый метод Child (dynamic dispatch),
        // хотя конструктор Child ещё не закончил выполняться!
        printValue();
    }

    void printValue() {}
}

class Child extends Parent {
    private final int value;

    Child() {
        // Неявный super() уже был вызван, и только после него полю "value" присвоится 42.
        this.value = 42;
    }

    @Override
    void printValue() {
        // Пока выполняется Parent(), здесь всё ещё значение по умолчанию - печатается 0, а не 42
        System.out.println(value);
    }
}

И вот OpenJDK хочет сделать шаг на пути исправления этой проблемы. В рамках JEP 539 завозят новый механизм "строгих полей" (strict fields). Их поведение будет немного отличаться в зависимости от того, static поле или нет, но цель одна - не допустить ситуации выше.

Например, если пометить value поле выше как strict (сейчас вы это никак не сделаете), то при загрузке класса будет VerifyError, т.к. строгие поля объектов необходимо присвоить до вызова super().

То есть Parent() уже не сможет вызвать printValue() и увидеть промежуточный 0: JVM отклонит некорректный байткод ещё при его проверке.

Зачем вообще нечто подобное делать? В основном ради Project Valhalla и концепции "Integrity By Default", о которой мы уже писали.

Java движется к value classes, а для них состояние объекта должно иметь гораздо более строгие гарантии. С точки зрения пользователя, Value классы нужны в основном для скаляризации (Вспоминаем девиз: "codes like a 'class', works like an 'int'"). А для того, чтобы JIT мог эффективно скаляризировать классы, он должен быть абсолютно уверен, что наблюдаемое им состояние объекта единственно верное, и остальные наблюдают его ровно таким же.

Проблема в том, что даже для final полей в Java это не так. С одной стороны из-за проблемы выше, а с другой из-за того, что final на самом деле не совсем final.

Соответственно, примерно через полгода мы уже, скорее всего, увидим эту фичу в preview. Подробнее можно почитать в самом JEP.

⚠️ Важно! Механизм строгих полей это opt-in механизм, который пока, по умолчанию, будет касаться только value классов. Существующий код механизм "строгих полей" пока не касается!.

🔗 JEP 539: https://openjdk.org/jeps/539