왜 java.util일까요?선택사항은 Serialable이 아닙니다. 이러한 필드를 사용하여 개체를 Serialize하는 방법

왜 java.util일까요?선택사항은 Serialable이 아닙니다. 이러한 필드를 사용하여 개체를 Serialize하는 방법

Enum 클래스는 Serialable이므로 Enum을 사용하여 개체를 직렬화하는 데 문제가 없습니다.다른 하나는 클래스에 java.util 필드가 있는 경우입니다.옵션 클래스이 경우, 다음의 예외가 발생합니다.java.io시리얼화 불가예외: java.util.선택적.

이런 수업들을 어떻게 다뤄야 하는지, 어떻게 연재합니까?원격 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);
        }
    }
}

이 답변은 "선택사항은 시리얼화 가능해야 하지 않을까요?"라는 제목의 질문에 대한 답변입니다.간단히 말하면 Java Lambda(JSR-335) 전문가 그룹이 검토했지만 거부한 것입니다.이 메모, 이 메모와 이 메모는 설계상의 주요 목표를 나타내고 있습니다.Optional반환값이 없을 가능성이 있는 경우 함수의 반환값으로 사용됩니다. 목적은 것입니다.Optional실제 값이 존재하는 경우 추출합니다.값이 없는 경우 발신자는 기본값을 대체하거나 예외를 발생시키거나 다른 정책을 적용할 수 있습니다. 메서드하여 fluent 메서드콜을 은 fluent 메서드는 fluent 메서드콜이 반환됩니다.Optional★★★★★★ 。

은 결코 된 것이 아니었다.Optional옵션 메서드 인수 또는 객체의 필드로 저장 등 다른 방법으로 사용됩니다.그리고 그 연장선상에서,Optionalserializable을 사용하면 네트워크를 통해 데이터를 지속적으로 저장하거나 전송할 수 있으며, 둘 다 원래 설계 목표를 훨씬 초과한 사용을 장려합니다.

으로 데이터를 보다 더 방법이 .Optionalgetter 등):getValue in squestion method를 합니다.Optional이 필드에서는 모든 발신자가 빈 값을 처리하기 위한 정책을 구현하도록 강제합니다.이것에 의해, 발신자간에 부주의한 동작이 발생할 가능성이 있습니다.대부분의 경우 필드의 코드 집합이 설정될 때 정책을 적용하는 것이 좋습니다.

은 ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★Optional를 들면, 수집품으로.List<Optional<X>> ★★★★★★★★★★★★★★★★★」Map<Key,Optional<Value>>을 사용하다은 자주 사용하는 것이 OptionalNull-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()각각 다음과 같다.

io 라이브러리 Javaslang)에는 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 separate의 합니다.value너무 많이 연재하고 있어요.

위한 같이 할 때 .이를 피하기 위한 기본 솔루션, 변수를 옵션 없이 제공하고 아래와 같이 getter에 문의할 때 옵션으로 가져옵니다. Optional<Integer> value = Optional.empty();로로 합니다.Integer value = null;

public class My implements Serializable {

        private static final long serialVersionUID = 1L;
        //Optional<Integer> value = Optional.empty(); //old code
        Integer value = null; //solution code without optional.

        public void setValue(Integer value ) {
           //this.value  = Optional.of(value); //old code with Optional
           this.value  = value ; //solution code without optional.
        }

        
        public Optional<Integer> getValue() {
            //solution code - return the value by using Optional.
            return Optional.ofNullable(value);
        }
}

Optional 클래스를 프로젝트에 복사하고 Serialable을 구현하는 사용자 정의 Optional을 직접 생성하기만 하면 됩니다.너무 늦지 않았다는 걸 깨달아서 하는 거야

언급URL : https://stackoverflow.com/questions/24547673/why-java-util-optional-is-not-serializable-how-to-serialize-the-object-with-suc