3

ライブラリのバージョン 1 に対してコードを記述したシナリオがありますが、代わりにライブラリのバージョン 2 を出荷したいと考えています。コードは出荷されているため、変更できません。v1 には存在し、v2 では削除されたライブラリのクラスまたはメンバーにアクセスしようとするのではないかと心配しています。

コードが新しいバージョンのライブラリにリンクするかどうかを確認するための簡単なチェックを行うツールを作成することは可能であると考えました。コードがリンクされていても、コードがまだ非常に壊れている可能性があることを理解しています。私は反対側からこれについて考えています-コードがリンクしない場合、問題があると確信できます。

私が見る限り、参照、メソッド呼び出し、およびライブラリ クラスへのフィールド アクセスのバイトコード チェックを実行してから、リフレクションを使用してクラス/メンバーが存在するかどうかをチェックする必要があります。

3 つの質問があります。

(1)そのようなツールは既に存在しますか?

(2)私が想像しているよりもずっと複雑で、重要なことを見逃しているような気がしますが、そうですか?

(3)メソッド呼び出し、参照などを見つけることができるようにバイトコードを検査できる便利なライブラリを知っていますか?

ありがとう！

4

5 に答える 5

2

バイナリ互換性チェッカーであるClirrがここで役立つと思います。

Clirrは、Javaライブラリをチェックして、古いリリースとのバイナリおよびソースの互換性を確認するツールです。基本的に、2セットのjarファイルを指定すると、ClirrはパブリックAPIの変更のリストをダンプします。Clirr Antタスクは、互換性のないAPIの変更を検出した場合にビルドを中断するように構成できます。継続的インテグレーションプロセスでは、Clirrはバイナリまたはソースの互換性の問題の偶発的な導入を自動的に防ぐことができます。

于 2010-05-25T12:04:16.420 に答える
2

IDE でライブラリを変更すると、考えられるすべてのコンパイル時エラーが発生します。

コードが別のライブラリを使用し、そのライブラリが更新されたライブラリを使用しない限り、他に何も必要ありません。

于 2010-05-25T11:43:11.600 に答える
1

Spring 構成ファイルには特に注意してください。クラス名はテキストとして構成され、実行時まで欠落として表示されません。

于 2010-05-25T11:52:14.757 に答える
0

あなたが言及したチェックは、JVM /Javaクラスローダーによって行われます。たとえば、クラスとインターフェイスのリンクを参照してください。

したがって、「リンクの試行」は、アプリケーションを実行しようとするだけで簡単に実行できます。もちろん、チェックを上げて、.class/.jarファイルのコレクションに対して自分でチェックを実行することもできます。BCELのようなサードパーティのバイトコードマニピュレータも同様のチェックを行うと思います。

タグの反映について言及されていることに気づきました。リフレクションを介してクラスをロード/メソッドを呼び出す場合、これを一般的に分析する方法はありません。

幸運を！

于 2010-05-25T12:07:09.330 に答える
0

ソース コードにアクセスできる場合は、新しいライブラリに対してソースをコンパイルできます。コンパイルできない場合は、間違いなく問題があります。コンパイルしても、プログラムがリフレクション、Spring などのある種の IoC を使用している場合、まだ問題が発生する可能性があります。

単体テストがある場合は、リンクエラーをより適切にキャッチできる変更が必要になる場合があります。

プログラムの .class ファイルしかない場合、クラスファイルをソースに逆コンパイルし、新しいライブラリに対してソースを再度コンパイルする以外に役立つツールはわかりませんが、それはあまり健全ではありません。

于 2010-05-25T11:59:40.063 に答える