これはまだ試していませんが、リスクがありそうです。私が考えているケースは、JiBX を使用して単純な VO クラスをインストルメント化することです。これらの VO は、AMF やその他のスキームでシリアル化される予定です。バイトコード拡張のような裏方の作業を行うと、一般的に何かが台無しになる可能性があるという私の疑いを確認または否定し、その理由に関する背景情報を提供できる人はいますか? また、JiBX の具体的な事例にも興味があります。
2 に答える
7
舞台裏では、シリアル化は反射を使用します。あなたのバイトコード操作はおそらくフィールドを追加しています。したがって、これらのフィールドを一時的なものとしてマークしない限り、通常のフィールドと同じようにシリアル化されます。
したがって、両側で同じバイトコード操作を実行した場合は、問題ありません。
まだ読んでいない場合は、下位互換性機能がどのように機能するかを理解するために、シリアル化のドキュメントを読む必要があります。基本的に、受信者が予期しないフィールドを送信でき、問題はないと思います。フィールドを見逃す可能性があり、受信側でデフォルト値を取得します。ただし、仕様でこれを確認する必要があります。
メソッドを追加するだけの場合はreadResolve()、シリアル化メカニズムで特に使用されるなどのようなものでない限り、シリアル化には影響しません。
于 2010-10-14T21:49:40.070 に答える
2
public または protected フィールドまたはメソッドをクラスに追加/変更/削除すると、逆シリアル化する機能に影響します。インターフェイスの追加も同様です。これらはとりわけ、シリアル化プロセスの一部としてストリームに書き込まれるserialVersionUIDを生成するために使用されます。serialVersionUID逆シリアル化中にクラスの がロードされたクラスと一致しない場合、失敗します。
クラス定義でを明示的に設定するserialVersionUIDと、これで取得できます。readObjectを実装することもできwriteObjectます。
極端な場合、Externalizableを実装して、オブジェクトのすべてのシリアル化を完全に制御できます。
絶対的な最悪のシナリオ (状況によっては非常に便利ですが) はwriteReplace、複雑なオブジェクトに実装して、シリアル化で一種の単純な値オブジェクトと交換することです。次に、逆シリアル化では、より単純な値オブジェクトを実装readResolveして、反対側の複雑なオブジェクトを再構築または検索できます。それを引き出す必要があるときはめったにありませんが、そうすると非常に楽しいです。
于 2010-10-15T06:06:56.667 に答える