Perché java.util.Optional non è serializzabile, come serializzare l'oggetto con tali campi

La classe Enum è Serializable quindi non ci sono problemi a serializzare l'oggetto con enumerazioni. L'altro caso è dove la classe ha i campi della classe java.util.Optional. In questo caso viene generata la seguente eccezione: java.io.NotSerializableException: java.util.Optional

Come gestire tali classi, come serializzarle? È possibile inviare tali oggetti a EJB remoto o tramite RMI?

Questo è l'esempio:

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

Questa risposta è in risposta alla domanda nel titolo, "Non dovrebbe essere facoltativo essere serializzabile?" La risposta breve è che il gruppo di esperti Java Lambda (JSR-335) lo ha considerato e rifiutato . Quella nota, e questa e questa indicano che l'obiettivo di progettazione principale per Optionaldeve essere utilizzato come valore di ritorno delle funzioni quando un valore di ritorno potrebbe essere assente. L'intento è che il chiamante controlli immediatamente Optionaled estragga il valore effettivo se presente. Se il valore è assente, il chiamante può sostituire un valore predefinito, generare un'eccezione o applicare altri criteri. Questa operazione viene in genere eseguita concatenando chiamate di metodi fluenti alla fine di una pipeline di flusso (o altri metodi) che restituiscono Optionalvalori.

Non è mai stato concepito per Optionalessere utilizzato in altri modi, ad esempio per argomenti di metodo opzionali o per essere memorizzato come campo in un oggetto . E per estensione, renderlo Optionalserializzabile consentirebbe di archiviarlo in modo persistente o trasmetterlo attraverso una rete, il che incoraggia entrambi gli usi ben oltre il suo obiettivo di progettazione originale.

Di solito ci sono modi migliori per organizzare i dati che memorizzare un Optionalin un campo. Se un getter (come il getValuemetodo nella domanda) restituisce l'effettivo Optionaldal campo, costringe ogni chiamante a implementare una politica per gestire un valore vuoto. Questo probabilmente porterà a comportamenti incoerenti tra i chiamanti. Spesso è meglio che qualsiasi set di codice in quel campo applichi una politica nel momento in cui è impostato.

A volte le persone vogliono mettere Optionalin raccolte, come List<Optional<X>>o Map<Key,Optional<Value>>. Anche questa di solito è una cattiva idea. Spesso è meglio sostituire questi usi di Optionalcon valori Null-Object (non nullriferimenti effettivi ) o semplicemente omettere completamente queste voci dalla raccolta.

Molti Serializationproblemi correlati possono essere risolti disaccoppiando il modulo serializzato persistente dall'effettiva implementazione del runtime su cui si 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;
    }
}

La classe Optionalimplementa un comportamento che permette di scrivere un buon codice quando si tratta di valori eventualmente assenti (rispetto all'uso di null). Ma non aggiunge alcun vantaggio a una rappresentazione persistente dei dati. Renderebbe i tuoi dati serializzati più grandi ...

Lo schizzo sopra potrebbe sembrare complicato, ma è perché mostra il modello con una sola proprietà. Più proprietà ha la tua classe, più dovrebbe essere rivelata la sua semplicità.

E non dimenticare, la possibilità di cambiare Mycompletamente l'implementazione senza alcuna necessità di adattare la forma persistente ...

Se desideri un facoltativo serializzabile, considera invece l'utilizzo dell'opzionale di guava che è serializzabile.

È una curiosa omissione.

Dovresti contrassegnare il campo come transiente fornire il tuo writeObject()metodo personalizzato che ha scritto il get()risultato stesso e un readObject()metodo che ripristina il Optionalleggendo quel risultato dallo stream. Senza dimenticare di chiamare defaultWriteObject()e defaultReadObject()rispettivamente.

La libreria Vavr.io (ex Javaslang) ha anche la Optionclasse che è serializzabile:

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

Se vuoi mantenere un elenco di tipi più coerente ed evitare di usare null, c'è un'alternativa stravagante.

È possibile memorizzare il valore utilizzando un'intersezione di tipi . Accoppiato con un lambda, questo consente qualcosa come:

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

Avere la tempvariabile separata evita di chiudersi sul proprietario del valuemembro e quindi di serializzare troppo.