Почему java.util.Optional не является сериализуемым, как сериализовать объект с такими полями

Этот ответ является ответом на вопрос в заголовке: «Разве необязательно должен быть сериализуемый?» Короткий ответ: группа экспертов Java Lambda (JSR-335) рассмотрели и отклонили. Это примечание и это и это указывает, что основной дизайн цель для Optional — использовать в качестве возвращаемого значения функций, когда возвращаемое значение может отсутствовать. Цель состоит в том, чтобы вызывающая сторона немедленно проверила Optional и извлекла фактическое значение, если оно присутствует. Если значение отсутствует, вызывающий объект может заменить значение по умолчанию, создать исключение или применить какую-либо другую политику. Обычно это делается путем связывания вызовов плавных методов с конца потокового конвейера (или других методов), которые возвращают Optional значений.

Никогда не предполагалось, что Optional будет использоваться другими способами, например, для дополнительных аргументов метода или как хранится как поле в объекте. Кроме того, создание сериализуемого Optional позволит хранить его постоянно или передавать по сети, что поощряет использование, выходящее далеко за рамки его первоначальной цели.

Обычно есть лучшие способы организовать данные, чем хранить Optional в поле. Если геттер (такой как метод getValue в вопросе) возвращает фактическое Optional из поля, это заставляет каждого вызывающего объекта реализовать некоторую политику для работы с пустым значением. Это, вероятно, приведет к непоследовательному поведению вызывающих абонентов. Часто лучше, чтобы любой код, установленный в этом поле, применял некоторую политику во время ее установки.

Иногда люди хотят поместить Optional в коллекции, например List<Optional<X>> или Map<Key,Optional<Value>>. Это тоже обычно плохая идея. Часто лучше заменить эти варианты использования Optional значениями Null-Object (не фактическими ссылками null), или просто полностью исключить эти записи из коллекции.

Многие проблемы, связанные с Serialization, можно решить, отделив постоянную сериализованную форму от фактической реализации среды выполнения, с которой вы работаете.

/** The class you work with in your runtime */
public class My implements Serializable {
    private static final long serialVersionUID = 1L;

    Optional<Integer> value = Optional.empty();

    public void setValue(Integer i) {
        this.value = Optional.ofNullable(i);
    }

    public Optional<Integer> getValue() {
        return value;
    }
    private Object writeReplace() throws ObjectStreamException
    {
        return new MySerialized(this);
    }
}
/** The persistent representation which exists in bytestreams only */
final class MySerialized implements Serializable {
    private final Integer value;

    MySerialized(My my) {
        value=my.getValue().orElse(null);
    }
    private Object readResolve() throws ObjectStreamException {
        My my=new My();
        my.setValue(value);
        return my;
    }
}

Класс Optional реализует поведение, которое позволяет писать хороший код при работе с возможными отсутствующими значениями (по сравнению с использованием null). Но это не добавляет никаких преимуществ к постоянному представлению ваших данных. Это просто сделало бы ваши сериализованные данные больше…

Эскиз выше может показаться сложным, но это потому, что он демонстрирует шаблон только с одним свойством. Чем больше свойств у вашего класса, тем больше должна раскрываться его простота.

И не забывайте, возможность полностью изменить реализацию My без необходимости адаптировать персистентную форму…

Если вам нужна сериализуемая опция, рассмотрите вместо этого использование необязательный для гуавы, который можно сериализовать.

Любопытное упущение.

Вам нужно будет пометить поле как transient и предоставить собственный пользовательский метод writeObject(), который записывает сам результат get(), и метод readObject(), который восстанавливает Optional, считывая этот результат из потока. Не забывая вызывать defaultWriteObject() и defaultReadObject() соответственно.

Библиотека Vavr.io (ранее Javaslang) также имеет сериализуемый класс Option:

public interface Option<T> extends Value<T>, Serializable { ... }

Если вы хотите поддерживать более согласованный список типов и избегать использования null, есть одна странная альтернатива.

Вы можете сохранить значение, используя пересечение типов. В сочетании с лямбдой это позволяет что-то вроде:

private final Supplier<Optional<Integer>> suppValue;
....
List<Integer> temp = value
        .map(v -> v.map(Arrays::asList).orElseGet(ArrayList::new))
        .orElse(null);
this.suppValue = (Supplier<Optional<Integer>> & Serializable)() -> temp==null ? Optional.empty() : temp.stream().findFirst();

Наличие отдельной переменной temp позволяет избежать закрытия владельца члена value и, таким образом, слишком большой сериализации.