Java.lang.ObjectがSerializable Interfaceを実装しないのはなぜですか？
可能性のある複製：
なぜJavaシリアライズ可能なインターフェースが必要ですか？
Java docsのSerializabilityによると：
クラスの直列化可能性は、Java.io.Serializableインターフェースを実装するクラスによって有効になります。このインターフェイスを実装しないクラスは、その状態がシリアル化または非シリアル化されません。直列化可能クラスのすべてのサブタイプは、それ自体が直列化可能です。シリアル化インターフェースにはメソッドやフィールドがなく、シリアル化可能であることのセマンティクスを識別するためだけに機能します
オブジェクトがすでにSerializableを実装していないのはなぜですか？シリアライズ可能にしたくないメンバーは、transientとして作成できます。デフォルトの直列化可能性を妨げるのはなぜですか？
直列化可能クラスのすべてのサブタイプは、それ自体が直列化可能です。
つまり、all作成した、作成した、または作成するクラスはすべてシリアライズ可能です。 transientはクラス全体ではなく、フィールドのみを除外します。
これは潜在的なセキュリティホールです-偶然に、シリアル化できます。あなたのDataSourceにデータベース認証情報を入れてください-この特定のDataSource実装の作成者がそのようなフィールドtransientを作成するのを忘れた場合ランダムなJavaオブジェクトをシリアル化するのは驚くほど簡単です。たとえば、外部thisへの暗黙の参照を保持する内部クラスを通じて。
コードを注意深く検査するのではなく、明示的に必要なシリアル化を許可するクラスのホワイトリストを使用する方が安全であり、不要なフィールドがシリアル化されないようにします。
さらに、もう言うことはできません：MySuperSecretClassはシリアライズ可能ではありません（単にSerializableを実装しないため）-ガット（フィールド）のみを除外できます。
1。Serializableはマーカーインターフェイスですが、これは空ですが、クラスがSerializableとマークされている場合、そのオブジェクトはSerializableであることを意味します。
2。 Java.lang.ObjectがSerializableを実装しなかった理由は、特定のフィールドをSerializableにしたくなく、その間違いをそのフィールドに一時的に追加しなかった場合、混乱。
。プログラマーにクラスのSerializableを実装させることにより、プログラマーは意識的にそれを実装したことを認識し、シリアル化すべきでないものをシリアル化しないようにするために必要な措置を講じる必要があります。
ほとんどのクラスはシリアライズ可能である必要はありません。現在の設計では、クラスがシリアライズ可能であることを簡単に確認できます。本質的には、コンパイラでチェックされた自己文書です。そうでなければ、おそらく次のようなものを書くでしょう：
/** DON'T SERIALIZE IT!!! */
class Connection { ... }
コメントよりも言語やライブラリの機能を備えた方がいいです。
永続化する必要があるオブジェクトにSerializableを実装する方が理にかなっており、クラスtransienntのすべてのフィールドを宣言するのはより面倒です。 Objectがすべてのクラスのルートであり、リフレクションに関連するクラスが含まれているため、ObjectクラスにSerializableを実装することは不適切です。