Por que java.util.Optional não é serializável, como serializar o objeto com tais campos

A classe Enum é Serializable, portanto, não há problema em serializar o objeto com enums. O outro caso é onde a classe possui campos da classe java.util.Optional. Nesse caso, a seguinte exceção é lançada: java.io.NotSerializableException: java.util.Optional

Como lidar com essas classes, como serializá-las? É possível enviar tais objetos para EJB Remoto ou por RMI?

Este é o exemplo:

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);
        }
    }
}

Essa resposta é uma resposta à pergunta do título, "O opcional não deve ser serializável?" A resposta curta é que o grupo de especialistas Java Lambda (JSR-335) considerou e rejeitou . Essa nota, e esta e esta indicam que o objetivo principal do projeto Optionalé ser usado como o valor de retorno de funções quando um valor de retorno pode estar ausente. A intenção é que o chamador verifique imediatamente Optionale extraia o valor real, se estiver presente. Se o valor estiver ausente, o chamador pode substituir um valor padrão, lançar uma exceção ou aplicar alguma outra política. Isso normalmente é feito encadeando chamadas de método fluentes no final de um pipeline de fluxo (ou outros métodos) que retornam Optionalvalores.

Nunca foi planejado para Optionalser usado de outras maneiras, como para argumentos de método opcionais ou para ser armazenado como um campo em um objeto . E, por extensão, tornar Optionalserializável permitiria que ele fosse armazenado de forma persistente ou transmitido através de uma rede, o que encoraja usos muito além de seu objetivo de design original.

Normalmente, existem maneiras melhores de organizar os dados do que armazenar um Optionalem um campo. Se um getter (como o getValuemétodo em questão) retorna o valor real Optionaldo campo, ele força cada chamador a implementar alguma política para lidar com um valor vazio. Isso provavelmente levará a um comportamento inconsisente entre os chamadores. Geralmente, é melhor fazer com que os conjuntos de códigos desse campo apliquem alguma política no momento em que são definidos.

Às vezes, as pessoas querem colocar Optionalem coleções, como List<Optional<X>>ou Map<Key,Optional<Value>>. Geralmente, isso também é uma má ideia. Muitas vezes é melhor substituir esses usos de Optionalpor valores de Objeto Nulo (não reaisnull referências ) ou simplesmente omitir totalmente essas entradas da coleção.

Muitos Serializationproblemas relacionados podem ser resolvidos desacoplando o formulário serializado persistente da implementação de tempo de execução real em que você opera.

/** 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;
    }
}

A classe Optionalimplementa um comportamento que permite escrever um bom código ao lidar com valores possivelmente ausentes (em comparação com o uso de null). Mas isso não adiciona nenhum benefício a uma representação persistente de seus dados. Isso apenas aumentaria seus dados serializados ...

O esboço acima pode parecer complicado, mas isso porque demonstra o padrão com apenas uma propriedade. Quanto mais propriedades sua classe tiver, mais sua simplicidade deve ser revelada.

E não se esqueça, a possibilidade de alterar a implementação de Mycompletamente sem qualquer necessidade de adaptar a forma persistente…

Se você quiser um opcional serializável, considere usar o opcional do guava, que é serializável.

É uma omissão curiosa.

Você teria que marcar o campo como transiente fornecer seu próprio writeObject()método customizado que escreveu o get()próprio resultado e um readObject()método que restaurou o Optionalao ler esse resultado do fluxo. Não esquecendo de ligar defaultWriteObject()e defaultReadObject()respectivamente.

A biblioteca Vavr.io (antigo Javaslang) também tem a Optionclasse que é serializável:

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

Se você deseja manter uma lista de tipos mais consistente e evitar o uso de null, há uma alternativa estranha.

Você pode armazenar o valor usando uma interseção de tipos . Juntamente com um lambda, isso permite algo como:

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();

Ter a tempvariável separada evita fechar sobre o proprietário do valuemembro e, portanto, serializar demais.