問題タブ [serialversionuid]

Clinet は JVM A で実行され、サーバーは JVM B で実行されます。クライアントからサーバーへのすべての EJB 呼び出しがあります。

クライアント側で期待される2つのオブジェクトのいずれか。

1. の配列LoanDocument

   また

2. BusinessServicesException

   /li>

BusinessServicesException拡張するようになりましCommonExceptionた。CommonException拡張しProjectExceptionます。ProjectException伸びExceptionます。

クライアント側での逆シリアル化の問題を回避するために、3 つの例外クラスすべて (クライアント側とサーバー側の両方) にserialVersionUID値を指定しました。1L

そうでなければ私は得る

したがって、3 つのクラスすべて (serialVersionUID =1L) で 1L を指定すると、問題が解決します。

現在、LoanDocumentオブジェクトは拡張されていますが、インターフェイスCommonDocumentObjectを持っているserialVersionUIDか実装していません。Serializable

しかしLoanDocument[]、クライアント側で成功するとserialVersionUID、逆シリアル化のために関連する例外が発生しませんか?

私は何度かテストしましたが、私はいつも同じようserialVersionUIDに forLoanDocumentと in を取得しますCommonDocumentObject.

サーバーとクリネットで以下のコードを使用するとserialVersionUID、両側で常に同じになります。

ただし、次の場合は常に異なりますBusinessServicesException.

これはシリアライゼーションとバージョニングに関する質問です。名前、作曲家などの楽譜を保存する音楽データベースであるプログラムがあります...ユーザーが次回の起動時にデータベースをリロードできるように、各曲を隠しフォルダーにシリアル化します。

さて、Song クラスで何かを変更しなければならないとき、それが互換性のある変更であればすべて問題ありません。互換性のない変更を行った場合、「Song」という同じ名前で VersionUID が異なる 2 番目のクラスを作成できるのではないかと考えていました。次に、ソングを読み取るときに、保存されたバージョンが最新バージョンと一致しない場合、ソングを古い UID に読み込むメソッドに移動し、一連の手順を実行して新しいバージョンに変換します。これは可能ですか？

同じ名前でパラメーターが異なる複数のメソッドを使用できることは知っています。これは、クラスと VersionUID またはその他の変数で機能しますか?

ありがとう！

シリアライゼーションがJavaとその最新バージョンでどのように機能するかを学ぼうとしています。私はこのようなラムダをシリアライズしようとしています:

serialVersionUIDしかし、変数が存在しないという警告がないことに気付きました。正常ですか？

実行時に生成されることはわかっていますが、定義することを強くお勧めします: https://docs.oracle.com/javase/8/docs/api/java/io/Serializable.html

シリアライズ可能なクラスが serialVersionUID を明示的に宣言しない場合、シリアライゼーション ランタイムは、Java(TM) オブジェクト シリアライゼーション仕様で説明されているように、クラスのさまざまな側面に基づいて、そのクラスのデフォルトの serialVersionUID 値を計算します。ただし、デフォルトの serialVersionUID 計算は、コンパイラの実装によって異なる可能性があるクラスの詳細に非常に敏感であり、逆シリアル化中に予期しない InvalidClassExceptions が発生する可能性があるため、すべてのシリアル化可能なクラスで serialVersionUID 値を明示的に宣言することを強くお勧めします。したがって、異なる Java コンパイラの実装間で一貫した serialVersionUID 値を保証するには、シリアライズ可能なクラスで明示的な serialVersionUID 値を宣言する必要があります。また、明示的な serialVersionUID 宣言では、可能な場合は private 修飾子を使用することを強くお勧めします。そのような宣言は、直接宣言するクラスにのみ適用されるためです。serialVersionUID フィールドは、継承されたメンバーとしては役に立ちません。配列クラスは明示的な serialVersionUID を宣言できないため、常にデフォルトの計算値を持ちますが、配列クラスでは serialVersionUID 値を一致させる必要はありません。

私は何をすべきか ？Lambda でどのように定義できますか?

ありがとう

Serializable を実装する 2 つの Java クラスがあります。両方の serialVersionUid を 1L に設定しました。

同僚は、すべてのクラスが一意のシリアル バージョン uid を持っている必要があり、同じシリアル バージョン uid を持っている場合、jvm はクラスを同等に扱うと言いました。等価性は、シリアル バージョンの uid ではなく、equals メソッドの結果に基づいていると思いました。

シリアル バージョンの uid はクラスのバージョンを示すために使用され、互換性のない方法でクラスが変更された場合は、シリアル バージョンの uid をインクリメントする必要があることを理解していました。

あれは正しいですか？1 の serialversion uid を使用しても問題ありませんか? または、Java クラスの serialversion uid が 1L であってはなりませんか?

互換性のある変更と serialVersionUID ( http://docs.oracle.com/javase/6/docs/platform/serialization/spec/version.html#6678 )についてアドバイスが必要です。

私は、RPCを使用して「サーバー」プロジェクトと通信する「クライアント」プロジェクトを持つシステムで作業しています（「サーバー」はDTOクラスを使用してDBからデータをエクスポートし、「クライアント」は同じDTOクラスを使用してそのデータを提示します）。

フィールドが DTO クラスに追加されたとき、チームは serialversionUID を変更しないことを決定したため、「サーバー」の新しいバージョンがデプロイされたときに、「クライアント」をすぐにデプロイする必要はありません。その DTO クラスの古いバージョンは新しいものと互換性があります。

しかし (両方のプロジェクトに数十のシステム インスタンスがあるため)、新しいバージョンの「クライアント」が新しいバージョンの DTO クラスと共にデプロイされ、「サーバー」が何らかの理由で古いバージョンのままである場合、新しいフィールドの DTO クラスが null に解決され、顧客には null として表示されますが、これは正しくない可能性があります。

この問題に対処するためのベスト プラクティスはありますか? DTOクラスのあらゆる種類の変更でUIDを変更できますが、変更が使用されていない場合でも、常に両方のプロジェクトを同時に展開する必要があり、それを回避しようとしています...

明示的な serialVersionUID を宣言することは、シリアライゼーションにはほとんど推奨されますが、シリアライゼーションの javadoc の最後の行に従って、配列クラスには推奨されません。

配列クラスは明示的な serialVersionUID を宣言できないため、常にデフォルトの計算値を持ちますが、配列クラスでは serialVersionUID 値を一致させる必要はありません。

javadoc が参照している配列クラスはどれですか? 私は、ユーティリティ クラスである Arrays と final である Array のみを認識しています。それで、懸念しているクラスは他にありますか？

配列クラスが明示的な serialVersionUID を宣言できないのはなぜですか?

別の投稿がありますが、配列クラスが serialVersionUID を宣言できない理由を説明していません

シリアル バージョン ID の不一致の問題に直面しています。

私のサーバーには、serialVersionID=20150301L のコードがあります。myt クライアント コードには違いがあるため、手動で変更しましたが、同じ問題に直面しています。

エラー：

サーバーと同じようにシリアライズ可能で手動で定義されたserialVersionIDを実装するようなオプションを試しましたが、毎回同じエラーが発生しました。