Tại sao java.util.Optional không Serializable, làm thế nào để tuần tự hóa đối tượng với các trường như vậy

Lớp Enum là Serializable nên không có vấn đề gì khi serialize đối tượng với enum. Trường hợp khác là lớp có các trường thuộc lớp java.util.Optional. Trong trường hợp này, ngoại lệ sau được ném ra: java.io.NotSerializableException: java.util.Optional

Làm thế nào để đối phó với các lớp như vậy, làm thế nào để tuần tự hóa chúng? Có thể gửi các đối tượng như vậy đến EJB từ xa hoặc thông qua RMI không?

Đây là ví dụ:

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

Câu trả lời này là để trả lời cho câu hỏi trong tiêu đề, "Không nên Tùy chọn có thể được nối tiếp?" Câu trả lời ngắn gọn là nhóm chuyên gia Java Lambda (JSR-335) đã xem xét và bác bỏ nó . Lưu ý đó, và điều này và điều này chỉ ra rằng mục tiêu thiết kế chính Optionallà được sử dụng làm giá trị trả về của các hàm khi giá trị trả về có thể không có. Mục đích là người gọi ngay lập tức kiểm tra Optionalvà trích xuất giá trị thực nếu nó hiện diện. Nếu giá trị không có, người gọi có thể thay thế một giá trị mặc định, đưa ra một ngoại lệ hoặc áp dụng một số chính sách khác. Điều này thường được thực hiện bằng cách chuỗi các lệnh gọi phương thức thông thạo ở cuối đường ống luồng (hoặc các phương thức khác) trả về Optionalgiá trị.

Nó không bao giờ được dự định Optionalsử dụng theo những cách khác, chẳng hạn như cho các đối số phương thức tùy chọn hoặc được lưu trữ dưới dạng một trường trong một đối tượng . Và bằng cách mở rộng, việc tạo Optionaltuần tự hóa sẽ cho phép nó được lưu trữ liên tục hoặc truyền qua mạng, cả hai đều khuyến khích việc sử dụng vượt xa mục tiêu thiết kế ban đầu của nó.

Thông thường, có nhiều cách tốt hơn để tổ chức dữ liệu hơn là lưu trữ Optionaltrong một trường. Nếu một getter (chẳng hạn như getValuephương thức trong câu hỏi) trả về giá trị thực Optionaltừ trường, nó buộc mọi người gọi thực hiện một số chính sách để xử lý một giá trị trống. Điều này có thể dẫn đến hành vi thiếu cân nhắc giữa những người gọi. Thường thì tốt hơn nếu có bất kỳ bộ mã nào mà trường đó áp dụng một số chính sách tại thời điểm nó được đặt.

Đôi khi mọi người muốn đưa Optionalvào bộ sưu tập, như List<Optional<X>>hoặc Map<Key,Optional<Value>>. Đây cũng là một ý tưởng tồi. Thông thường tốt hơn là thay thế các cách sử dụng này Optionalbằng các giá trị Null-Object (không phải nulltham chiếu thực tế ) hoặc đơn giản là loại bỏ hoàn toàn các mục nhập này khỏi bộ sưu tập.

Rất nhiều Serializationvấn đề liên quan có thể được giải quyết bằng cách tách biểu mẫu được tuần tự hóa liên tục khỏi việc triển khai thời gian chạy thực tế mà bạn thao tác.

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

Lớp Optionalthực hiện hành vi cho phép viết mã tốt khi xử lý các giá trị có thể vắng mặt (so với việc sử dụng null). Nhưng nó không thêm bất kỳ lợi ích nào cho việc trình bày liên tục dữ liệu của bạn. Nó sẽ chỉ làm cho dữ liệu được tuần tự hóa của bạn lớn hơn…

Bản phác thảo ở trên có thể trông phức tạp nhưng đó là vì nó thể hiện mô hình chỉ với một thuộc tính. Lớp của bạn càng có nhiều thuộc tính thì tính đơn giản của nó càng được tiết lộ.

Và đừng quên, khả năng thay đổi việc triển khai Myhoàn toàn mà không cần phải điều chỉnh hình thức liên tục…

Nếu bạn muốn một tùy chọn có thể tuần tự hóa, hãy xem xét thay vào đó sử dụng tùy chọn của ổi có thể được tuần tự hóa.

Đó là một thiếu sót đáng tò mò.

Bạn sẽ phải đánh dấu trường là transientvà cung cấp writeObject()phương thức tùy chỉnh của riêng bạn đã viết get()chính kết quả và một readObject()phương thức khôi phục Optionalbằng cách đọc kết quả đó từ luồng. Không quên gọi defaultWriteObject()và defaultReadObject()tương ứng.

Thư viện Vavr.io (Javaslang cũ) cũng có Optionlớp có thể tuần tự hóa:

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

Nếu bạn muốn duy trì một danh sách loại nhất quán hơn và tránh sử dụng null, có một lựa chọn thay thế khó hiểu.

Bạn có thể lưu trữ giá trị bằng cách sử dụng giao nhau của các loại . Được kết hợp với lambda, điều này cho phép một cái gì đó như:

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

Việc có tempbiến riêng biệt sẽ tránh đóng lại chủ sở hữu của valuethành viên và do đó nối tiếp quá nhiều.