ObjectInputStreamデータをデバッグ/表示するにはどうすればよいですか？

Question

ソケットを介してクライアントアプリケーションにシリアル化されたJavaオブジェクトを送信するagentmainを使用して、リモートプロセスにjavaagentをアタッチしました。

ストリームの書式設定にバグがあります。私はwriteExternal実装でエラーが発生しているかどうか、またはそれがJavaバージョンと関係があるかどうかわかりません。私はJava 1.6 32/64ビットのさまざまな組み合わせを試しています。

基本的に、オブジェクトストリームは例外が見つかりませんでしたが、出力されるパッケージ名はorg.mycode.bebのようなものです。beb部分は自分が所有するパッケージとは無関係で、その文字列を持つコードまたはライブラリには何もありません... beb

エンコード形式の不一致または32/64ビットの語長の問題のために発生するエンコードの問題であると疑われていますが、私はこれらの分野での経験はありません。

私は、コードの問題を追跡するためにデバッガを開くのによく慣れていますが、シリアライゼーションとバイトフォーマットでこのような問題を診断する経験はあまりありませんので、推奨されるデバッグ方法を教えてください。現在org.mycode.b.e.bが見つかりませんクラスをスロー

objectInput = new ObjectInput(inputStream); 
Object object = objectInput.readObject(); 

：

は、私のようなコードを使用するクライアントの制御/コンパイル/ソースを持っています。

シリアライズされたストリームをファイルに保存して見てみようと思っていましたが、それは正しい角度ですか？

Answer 1

32ビットまたは64ビット、またはビッグエンディアンまたはリトルエンディアンのいずれのマシンでも、ObjectOutputStreamのフォーマットは変更されません。過去に問題があった場所は、Java 1.3とJava 1.4の間で、わずかに異なるフォーマットを使用していました。また、EclipseとSunはserialVersionUIDを生成するために異なるalgosを使用していました。ハードコードしないと問題に遭遇する可能性があります。

しかし、b.e.bのようなパッケージを使用している場合は、コードを難読化している可能性があります。これは、作業が難しくなるように設計されています。あなたは難読化されていないコードをデバッグ/監視することをお勧めします。

Answer 2

@Peter Lawreyの功績に加えて。

私はあなたのデバッグを簡略化するために、難読化されていないコードで作業すべきだと思います。これは、少なくとも問題のあるヒントを提供します。

おそらく部分的な難読化が問題の根本原因です。あなたはオブジェクトが難読化されていないクライアント側で直列化されていると考えてください。 MyFirstClassという名前のクラスがMySecondClassに依存し、それに応じてシリアル化されているとします。しかし、サーバー側では、MySecondClassの名前はqです。なぜqですか？これは難読化しなければなりません。さらに、この名前はビルドごとに異なる場合があります。したがって、サーバー側はクラスMySecondClassを見つけることができません。

その他の問題はserialiVersionUIDです。おそらく、関連するすべてのクラスに対してこの変数を定義し、その値を処理する必要があります。

しかし、まず難読化を避けて、もう一度やり直してください。私はすべてがうまくいくと思います。がんばろう。