なぜJavaはSerializableインターフェースを必要とするのですか？

シリアライゼーションにはかなりの労力を費やしていますが、使用するすべてのオブジェクトにSerializableタグを指定しなければならないのは、ちょっとした負担です。特にそれが私たちが実際に変更することができないサードパーティのクラスである場合。

問題は次のとおりです。Serializableは空のインターフェイスであり、Javaは追加すると堅牢なシリアル化を提供する implements Serializableので、なぜそれらはすべてをシリアル化可能にしていないのですか？

何が欠けていますか？

シリアライゼーションには落とし穴があります。このフォームの自動シリアル化サポートにより、クラスの内部はパブリックAPIの一部になります（そのため、javadocは永続化されたクラスのフォームを提供します）。

長期的な永続性のために、クラスはこのフォームをデコードできる必要があります。これにより、クラス設計に加えることができる変更が制限されます。これはカプセル化を壊します。

シリアライゼーションもセキュリティの問題につながる可能性があります。参照のあるオブジェクトをシリアル化できるようにすることで、クラスは（結果のバイトデータを解析して）通常はできないデータにアクセスできます。

他にも、内部クラスのシリアル化された形式が適切に定義されていないなどの問題があります。

すべてのクラスをシリアライズ可能にすると、これらの問題が悪化します。「Effective Java Second Edition」、特にItem 74：Implement Serializableを慎重にチェックしてください。

今回はJavaと.Netの両方の人々が間違っていたと思います。デフォルトですべてをシリアライズ可能にして、代わりに安全にシリアライズできないクラスをマークする必要があるだけの方がいいでしょう。

たとえば、Smalltalk（70年代に作成された言語）では、すべてのオブジェクトがデフォルトでシリアライズ可能です。オブジェクトの大部分がシリアル化しても安全であり、そのうちのいくつかはそうでないという事実を考えると、これがJavaに当てはまらない理由はわかりません。

オブジェクトを（インターフェースで）シリアライズ可能としてマークしても、そのオブジェクトは魔法のようにシリアライズ可能ではありません。それはずっとシリアライズ可能でした。システムが独自に見つけたものを表現しただけなので、本当の理由はありませんシリアライゼーションは現在の方法です。

設計者が下した決定の悪さか、シリアル化が後付けだったのか、プラットフォームがすべてのオブジェクトに対してデフォルトで安全かつ一貫してシリアル化する準備ができていなかったと思います。

すべてが真にシリアル化可能であるとは限りません。たとえば、ネットワークソケット接続を考えてみます。ソケットオブジェクトのデータ/状態をシリアル化できますが、アクティブな接続の本質は失われます。

JavaでのSerializableの主な役割は、デフォルトで、他のすべてのオブジェクトを実際には非直列化できるようにすることです。シリアライゼーションは、特にデフォルトの実装では、非常に危険なメカニズムです。したがって、C ++の友情と同様に、シリアライズ可能にするのに少しコストがかかっても、デフォルトではオフになっています。

構造の互換性は保証されていないため、シリアライゼーションは制約と潜在的な問題を追加します。デフォルトではオフになっているのが良いです。

私は、標準のシリアル化が私が望んでいることを行う重要なクラスをほとんど見たことがないことを認めなければなりません。特に複雑なデータ構造の場合。したがって、クラスをシリアライズ可能にするために費やす労力は、インターフェースを追加するコストに相当します。

一部のクラス、特にファイル、ソケット、スレッド、またはDB接続などのより物理的なクラスを表すクラスでは、インスタンスをシリアル化してもまったく意味がありません。他の多くの場合、シリアライゼーションは一意性の制約を破壊するか、クラスの異なるバージョンのインスタンスを処理するように強制するだけなので、望ましくない可能性があるため、問題が発生する可能性があります。

間違いなく、デフォルトですべてをシリアライズ可能にし、キーワードまたはマーカーインターフェイスを介してクラスをシリアライズ不可能にする方が良いかもしれませんが、そのオプションを使用する必要がある人はおそらくそれについて考えないでしょう。それがそうであるように、Serializableを実装する必要がある場合は、例外によってそのことが通知されます。

ただし、プログラマとして、オブジェクトがシリアル化されることを確認する必要があったと思います。

どうやらすべてはいくつかの予備設計でシリアライズ可能でしたが、セキュリティと正確さの懸念のために、最終的な設計は誰もが知っているようになってしまいました。

出典：ObjectOutputStreamに書き込むために、クラスでSerializableを実装する必要があるのはなぜですか？。

特定のクラスのインスタンスがSerializableであることを明示的に述べる必要がある場合、言語はそれを許可する必要があるかどうかについて考えることを強いられます。単純な値オブジェクトの場合、シリアル化は簡単ですが、より複雑なケースでは、物事をじっくりと考える必要があります。

JVMの標準のシリアル化サポートに依存するだけで、あらゆる種類の厄介なバージョン管理の問題にさらされることになります。

一意性、「実際の」リソースへの参照、タイマー、および他の多くのタイプのアーティファクトは、シリアル化の候補ではありません。

これを読んで、Serializable Interfaceを理解し、なぜいくつかのクラスだけをSerializableにする必要があるのか​​を理解します。また、ストアドプロシージャからいくつかのフィールドを削除する場合に備えて、transientキーワードをどこで使用するかについて注意する必要があります。

http://www.codingeek.com/java/io/object-streams-serialization-deserialization-java-example-serializable-interface/

まあ、私の答えは、これは正当な理由がないということです。そして、あなたのコメントから、あなたはすでにそれを学んだことがわかります。他の言語は、10に数えた後、ツリーにジャンプしないすべてのものを喜んでシリアライズしようとします。オブジェクトはデフォルトでシリアライズ可能である必要があります。

したがって、基本的に必要なことは、サードパーティクラスのすべてのプロパティを自分で読み取ることです。または、それが選択肢である場合は、逆コンパイルし、damnキーワードをそこに置いて、再コンパイルします。

Javaには、ランタイム固有であるため単純にシリアライズできないものがあります。ストリーム、スレッド、ランタイムなどのようなもの、および一部のGUIクラス（基盤となるOSに接続されているもの）でさえ、シリアル化できません。

ここで他の回答で述べた点に同意しますが、実際の問題は逆シリアル化にあります。クラス定義が変更されると、逆シリアル化が機能しないという実際のリスクがあります。既存のフィールドを変更しないことは、ライブラリの作成者が作成するかなり重要な取り組みです！APIの互換性を維持することは、現状では十分な作業です。

ファイルまたは他のメディアに永続化する必要があるクラスは、Serializableインターフェースを実装して、JVMがクラスオブジェクトをシリアル化できるようにする必要があります。ObjectOutputStreamを使用する場合にのみすべてのJVMがクラスをシリアル化した後、オブジェクトクラスがシリアル化されない理由は、どのクラスもインターフェイスを実装する必要がないということです。

クラスのバージョンが大きな問題であるにもかかわらず、Objectクラスがデフォルトでシリアル化できない理由。したがって、シリアライゼーションに関係する各クラスは、明示的にSerializableとしてマークし、バージョン番号serialVersionUIDを提供する必要があります。

serialVersionUIDが指定されていない場合、オブジェクトのデシリアライズ中に予期しない結果が発生します。そのため、serialVersionUID が一致しない場合、JVMはInvalidClassExceptionをスローします。したがって、すべてのクラスはSerializableインターフェースを実装し、serialVersionUIDを提供して、両端に表示されるクラスが同一であることを確認する必要があります。