Dlaczego java.util.Optional nie można serializować, jak serializować obiekt za pomocą takich pól

Klasa Enum jest Serializable, więc nie ma problemu z serializacją obiektu za pomocą wyliczeń. W drugim przypadku klasa ma pola klasy java.util.Optional. W takim przypadku zgłaszany jest następujący wyjątek: java.io.NotSerializableException: java.util.Optional

Jak sobie radzić z takimi klasami, jak je serializować? Czy można wysłać takie obiekty do zdalnego EJB lub przez RMI?

Oto przykład:

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

Ta odpowiedź jest odpowiedzią na pytanie w tytule „Czy opcjonalny nie powinien być serializowany?” Krótka odpowiedź jest taka, że ​​grupa ekspertów Java Lambda (JSR-335) rozważyła to i odrzuciła . Ta uwaga, ta i ta wskazują, że głównym celem projektu Optionaljest użycie jako wartości zwracanej funkcji, gdy wartość zwracana może być nieobecna. Celem jest, aby wywołujący natychmiast sprawdził Optionali wyodrębnił rzeczywistą wartość, jeśli jest obecna. Jeśli wartość jest nieobecna, obiekt wywołujący może zastąpić wartość domyślną, zgłosić wyjątek lub zastosować inne zasady. Odbywa się to zwykle przez połączenie wywołań metod płynnych na końcu potoku strumienia (lub innych metod), które zwracają Optionalwartości.

Nigdy nie było przeznaczone Optionaldo używania go w inny sposób, na przykład do opcjonalnych argumentów metod lub do przechowywania jako pole w obiekcie . A co za tym idzie, umożliwienie Optionalserializacji umożliwiłoby trwałe przechowywanie lub przesyłanie przez sieć, co zachęca do zastosowań daleko wykraczających poza pierwotny cel projektu.

Zwykle istnieją lepsze sposoby organizowania danych niż przechowywanie Optionalw polu. Jeśli getValuemetoda pobierająca (taka jak metoda w pytaniu) zwraca wartość rzeczywistą Optionalz pola, to zmusza każdego wywołującego do zaimplementowania pewnych zasad postępowania z wartością pustą. Prawdopodobnie doprowadzi to do niespójnego zachowania wszystkich rozmówców. Często lepiej jest mieć dowolny kod ustawiany przez to pole, który stosuje pewne zasady w momencie ich ustawiania.

Czasami ludzie chcą umieścić je Optionalw kolekcjach, takich jak List<Optional<X>>lub Map<Key,Optional<Value>>. To też jest zazwyczaj zły pomysł. Jest to często lepiej zastąpić te zwyczaje Optionalz Null-Object wartości (a nie rzeczywiste nullreferencje), lub po prostu pominąć te wpisy z kolekcji w całości.

Wiele Serializationpowiązanych problemów można rozwiązać, oddzielając trwały formularz serializowany od rzeczywistej implementacji środowiska uruchomieniowego, na którym działasz.

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

Klasa Optionalimplementuje zachowanie, które pozwala napisać dobry kod w przypadku potencjalnie nieobecnych wartości (w porównaniu do użycia null). Ale to nie dodaje żadnych korzyści do trwałej reprezentacji twoich danych. To po prostu zwiększyłoby twoje zserializowane dane ...

Powyższy szkic może wyglądać na skomplikowany, ale to dlatego, że przedstawia wzór tylko z jedną właściwością. Im więcej właściwości ma twoja klasa, tym bardziej powinna być ujawniona jej prostota.

I nie zapominajmy, że możliwość zmiany wykonania Mycałkowicie bez konieczności dostosowywania trwałej formy…

Jeśli chcesz serializowalny opcjonalny, rozważ zamiast tego użycie opcjonalnego guawy, który można serializować.

To dziwne zaniedbanie.

Musisz oznaczyć pole jako transienti podać własną niestandardową writeObject()metodę, która zapisała get()sam wynik, oraz readObject()metodę, która przywróciła wynik Optional, odczytując ten wynik ze strumienia. Nie zapomnij zadzwonić defaultWriteObject()i defaultReadObject()odpowiednio.

Biblioteka Vavr.io (dawniej Javaslang) ma również Optionklasę, którą można serializować:

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

Jeśli chcesz zachować bardziej spójną listę typów i unikać używania null, jest jedna dziwna alternatywa.

Możesz zapisać wartość, używając przecięcia typów . W połączeniu z lambdą pozwala to na coś takiego:

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

Oddzielenie tempzmiennej pozwala uniknąć zamykania właściciela elementu valueczłonkowskiego, a tym samym zbyt dużej serializacji.