問題タブ [serialversionuid]

重複の可能性:
serialVersionUID を気にする必要があるのはなぜですか?

Struts2 の検証ドキュメントを調べていました。ここでも次のように定義されています。

serialVersionUID を使用する目的は何ですか、それを使用する方法(乱数を使用しますか?)、およびそのドキュメントで使用する目的は何ですか?

サーバーとの通信にシリアル化を使用しています。JTreeこのようにして、私のアプレットはサーバーで作成されたものを取得します。eclipseとappletViewerでは、アプレットは完全に機能しますが、サーバーからアプレットを起動しようとすると、コンソールでこのエラーが発生しました。

java.io.InvalidClassException：javax.swing.JComponent; ローカルクラスに互換性がありません：ストリームclassdesc serialVersionUID = 5858390075012080263、ローカルクラスserialVersionUID = -1030230214076481435

プロジェクトのすべてのクラスのserialVersionUIDを取得しようとしましserialverたが、いずれも 取得していませんserialVersionUID = 5858390075012080263。

オブジェクトを逆シリアル化しようとすると、エラーが発生します。これに加えて、エラーは言う

java.io.InvalidClassException: javax.swing.JComponent。

JComponentこのエラーの原因を特定するにはどうすればよいですか？それは私のJTreeですか？serialVersionUIDを設定するにはどうすればよいですか？このJComponentを拡張するクラスを作成し、serialVersionUIDを設定しますか？

私は現在、Android と Windows の間で通信するリモート アクターをテストしています。アクターのリモートは、serialVersionUID を設定したさまざまなクラスを送信します。

これは私のシリアル化されたクラスのコードです:

問題は、リモート アクターのデバッグで、互換性のないクラスに問題があると表示されることです。

SerialVersionUID がコンパイラにとって問題にならないのはなぜですか?

serialVersionUID を修正するにはどうすればよいですか? または多分別の問題がありますか？

ありがとう

重複の可能性：
serialVersionUIDについて気にする必要があるのはなぜですか？

いくつかの例外処理コードを実行していますが、serialVersionUIDという名前のコードが表示されました。このuidは何のためにありますか？例外に限定されているのですか、それともすべてのクラスで使用できますか？このIDの利点は何ですか？

Web アプリケーションの一般的なシナリオ:

• アプリケーションには、Session に格納する必要があり、シリアライズ可能なクラスが多数あります
• 開発者は、「Serializable クラスは serialVersionUID を実装していません」という警告を大量に受け取ります。
• 開発者が肩をすくめて IDE の「serialversionUID を追加」をクリックすると、問題は解決しますか?

ソリューションは本質的にそれを意味するため、原則としてserialVersionUIDを自動的に追加するのは好きではありません

• 最も重要なことは、開発者が「自分の変更がいつシリアル化を壊すのか、いつ壊さないのかを知っていて、JVM の代わりにそれを制御したい」と述べていることですが、実際には、彼はそれらのことを知らず、それらを制御したくないのです。
• serialVersionUID = 6266256561409620894L を追加するのは紛らわしく醜いです (わかりました、1L を使用できます)。

クラスの互換性が問題となるアプリケーションに serialVersionUID を追加することを理解しており、開発者は積極的にそれを考慮し、関連する問題を理解しています。

典型的な Web アプリケーションでは、クラスのシリアル化がいつ壊れるかどうかはあまり重要ではありません。新しいバージョンがデプロイされると、関係のないシリアライズされたセッションが壊れることがありますが、通常は問題になりません (また、シリアライズされたセッションのバージョン互換性を実際に適切に処理するアプリケーションはほとんどありません)。

結論: 「ソース ファイルで serialVersionUID を常に明示的に定義する」というアドバイスは単純ではありませんか?

私は最近、同じクラスの異なるバージョンをシリアル化/逆シリアル化と互換性のあるものにするためにserialVersionUIDを使用する必要がなくなったというコメントを、Java5以降で読みました。これは正しいです？多分それは共変のリターンタイプと混同されました。だから皆さんと一緒にチェックしたかったのです。

アプリケーションのデバッグの一環として、インターフェイスを拡張するクラスField.getDeclaredFields()のフィールドを含むいくつかの合成フィールドが返されることに気付きましたが、拡張するものはありません。serialVersionUIDSerializable

なぜコンパイラはそのようなフィールドを追加するのですか？

アップデート

$VRc実際、作成された合成フィールドもあります。

クラス Exception (新しい例外を作成するため) を使用してクラスを拡張すると、serialVersionUID. シリアル化と逆シリアル化の際に重要な役割を果たすことは知っていserialVersionUIDますが、いつ例外をシリアル化する必要がありますか? カスタム例外クラスにシリアライゼーションとデシリアライゼーションを持たせたい実用的なケースを誰か教えてもらえますか?

hbm2ddlMavenプラグインを使用して目標を追加すると、このDDL（postgresターゲット）が取得されhibernate3-maven-pluginます。

表示されているすべての列を定義しました。

私がウェブ上で見た使用のすべての例：

@Column注釈はありません。私のDDLにはそのための列がありません。他に誰かいますか？

では、Javaの逆シリアル化コードは、どのバージョンのクラスがシリアル化および保存されているのか、それが逆シリアル化されているのかをどのように知るのでしょうか。

Externalizable を実装する場合、バージョンの互換性のためにそのクラスで serialVersionUID を指定する必要がありますか?

つまり、Externalizable オブジェクトをデシリアライズする際に、Java は serialVersionUID をチェックしますか?