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

Класс Enum является сериализуемым, поэтому нет проблем с сериализацией объекта с помощью перечислений. Другой случай - когда у класса есть поля класса java.util.Optional. В этом случае выдается следующее исключение: java.io.NotSerializableException: java.util.Optional

Как бороться с такими классами, как их сериализовать? Можно ли отправлять такие объекты в Remote EJB или через RMI?

Вот пример:

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectOutputStream;
import java.io.Serializable;
import java.util.Optional;

import org.junit.Test;

public class SerializationTest {

    static class My implements Serializable {

        private static final long serialVersionUID = 1L;
        Optional<Integer> value = Optional.empty();

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

        public Optional<Integer> getValue() {
            return value;
        }
    }

    //java.io.NotSerializableException is thrown

    @Test
    public void serialize() {
        My my = new My();
        byte[] bytes = toBytes(my);
    }

    public static <T extends Serializable> byte[] toBytes(T reportInfo) {
        try (ByteArrayOutputStream bstream = new ByteArrayOutputStream()) {
            try (ObjectOutputStream ostream = new ObjectOutputStream(bstream)) {
                ostream.writeObject(reportInfo);
            }
            return bstream.toByteArray();
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
}

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

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

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

Иногда люди хотят складывать Optionalв коллекции, лайкать List<Optional<X>>или Map<Key,Optional<Value>>. Это тоже обычно плохая идея. Это часто лучше заменить эти обычаи Optionalс Null-объектными значениями (не фактические 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без необходимости адаптировать постоянную форму…

Если вы хотите сериализуемую опцию, рассмотрите возможность использования опциональной guava, которая является сериализуемой.

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

Вам нужно будет пометить поле как 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члена и, следовательно, слишком частой сериализации.