34 個の外部 jar を使用する既存の Java アプリケーションに取り組んでいます。
私の仕事の一部は、コードをよりクリーンで肥大化させないようにすることです。パスから削除してコードをテストすることで、まったく使用されていないライブラリを簡単に見つけることができます。
ただし、ごく一部しか使用されていないライブラリがいくつかあると思います (1 つまたは 2 つの関数である可能性があります)。
たとえば、一部の UI 構築用のライブラリがあります。ただし、アプリケーション コードでは、ログ機能の 1 つまたは 2 つしか使用していなかったと思われます。私は実際にその関数の独自のバージョンを実装し、アプリケーションをそのライブラリから完全に解放することができます。
コードを手動で調査することはできないため、アプリケーション コードでライブラリのコードがどれだけ使用されているかを確認するために使用できる既存のツールはありますか?
JDependはアプリケーション クラスの直接的な依存関係を示すことができますが、(少なくとも) 2 つの理由から、どの JAR を削除できるかは実際にはわかりません。
Class.forName。おそらく最も簡単なのは、JDepend から始めて、必要であると指示された JAR だけでビルドすることです。次に、実行時に、必要な追加の JAR を示す class-not-found 例外が発生します。
編集：
コードを手動で調査することはできないため、アプリケーション コードでライブラリのコードがどれだけ使用されているかを確認するために使用できる既存のツールはありますか?
質問を読み直したところ、単純な依存関係分析よりも的を絞ったものを求めていることに気付きました。コード カバレッジ ツールが正しい方向性を示してくれると思います。いくつかのオープンソースの可能性:
アプリケーション全体をインストルメント化してから通常どおりに実行し、実際に呼び出されるクラスを確認できます。ただし、完全に実行する必要があります。Java は必要に応じてクラスをロードするため、アプリケーションは一部の機能のみをクラスに依存する場合があります。
proguardのようなものを使用して古い未使用のコードを特定する傾向がありますが、他にもたくさんの機能がありますが、それらはあなたの質問には関係ありません。
JAR が開始するパッケージのコードと xml を検索できます。
ビルドから削除してプログラムを再ビルドし、コンパイル時にテストします。
迅速かつ汚い戦略として、すべてのアプリケーション コードを再帰してすべてのインポートを抽出するスクリプトを作成し、それらを使用頻度の低いものから順に並べ替え、ベース インポート パッケージの構造を jar に一致させてから、最もインポートされていない jar がどこで使用されているかを調べることを選択できます。 .
長期的な分析を改善するには、まずこれらの問題を解決してみてください。まず、可能であれば、標準のビルド ツール (maven など) を使用してアプリケーションを変換することをお勧めします。次に、Eclipse などの標準的な IDE でアプリケーションを動作させてビルドします。
これで、必要なことを実行できるようにするプラグインを検索して使用できるようになりました。
例：maven
mvn 依存関係:分析
同じことができるEclipseプラグインを見てください
例えば
http://classpathhelper.sourceforge.net/
今後も整備性はあります
これは前もって追加の作業が必要になる場合がありますが、コードをより適切に分析できるほど、タスクは高速になります。マスターになりたい場合は、Eclipse プラグインを作成して共有することもできます。