เหตุใด java.util.Optional จึงไม่สามารถต่ออนุกรมได้วิธีการทำให้วัตถุเป็นอนุกรมกับช่องดังกล่าว

คลาส Enum สามารถต่ออนุกรมได้ดังนั้นจึงไม่มีปัญหาในการทำให้วัตถุเป็นอนุกรมกับ enums อีกกรณีคือที่คลาสมีฟิลด์ของคลาส 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);
        }
    }
}

คำตอบนี้เป็นคำตอบสำหรับคำถามในหัวข้อ "ไม่จำเป็นต้องเป็นตัวเลือกต่อเนื่องหรือไม่" คำตอบสั้น ๆ ว่า (JSR-335) กลุ่ม Java แลมบ์ดาผู้เชี่ยวชาญพิจารณาและปฏิเสธมัน โน้ตนั้นและอันนี้และอันนี้ระบุว่าเป้าหมายหลักในการออกแบบOptionalเพื่อใช้เป็นค่าส่งคืนของฟังก์ชันเมื่อค่าที่ส่งคืนอาจไม่มี จุดประสงค์คือผู้โทรตรวจสอบOptionalและดึงค่าจริงทันทีหากมีอยู่ หากไม่มีค่าผู้โทรสามารถแทนที่ค่าเริ่มต้นโยนข้อยกเว้นหรือใช้นโยบายอื่น ๆ โดยทั่วไปจะทำได้โดยการผูกมัดวิธีการที่คล่องแคล่วเรียกการสิ้นสุดของไปป์ไลน์สตรีม (หรือวิธีการอื่น ๆ ) ที่ส่งคืนOptionalค่า

มันก็ไม่ได้มีไว้สำหรับการOptionalที่จะใช้วิธีการอื่น ๆ เช่นสำหรับข้อโต้แย้งวิธีการที่ไม่จำเป็นหรือที่จะเก็บไว้เป็นข้อมูลในวัตถุ และโดยการขยายการทำให้เป็นOptionalอนุกรมจะช่วยให้สามารถจัดเก็บได้อย่างต่อเนื่องหรือส่งผ่านเครือข่ายซึ่งทั้งสองอย่างนี้สนับสนุนให้ใช้เกินเป้าหมายการออกแบบเดิม

โดยปกติแล้วจะมีวิธีที่ดีกว่าในการจัดระเบียบข้อมูลมากกว่าการจัดเก็บOptionalในเขตข้อมูล หาก getter (เช่นgetValueวิธีการในคำถาม) ส่งคืนค่าจริงOptionalจากฟิลด์จะบังคับให้ผู้เรียกใช้นโยบายบางอย่างเพื่อจัดการกับค่าว่าง ซึ่งอาจนำไปสู่พฤติกรรมที่ไม่สอดคล้องกันระหว่างผู้โทร มักจะดีกว่าที่จะมีชุดรหัสใด ๆ ที่ฟิลด์นั้นใช้นโยบายบางอย่างในเวลาที่กำหนด

บางคนต้องการที่จะนำOptionalเข้ามาในคอลเลกชันเหมือนหรือList<Optional<X>> Map<Key,Optional<Value>>ซึ่งมักจะเป็นความคิดที่ไม่ดี มักจะดีกว่าที่จะแทนที่การใช้งานเหล่านี้Optionalด้วยค่า Null-Object (ไม่ใช่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สมาชิกและทำให้เป็นอนุกรมมากเกินไป