現在、Java プロジェクトをコンパイルするために、非常に大きなクラスパスを javac に渡しています。
これらの jar ファイルの多くが必要ないことはわかっています。
不要なファイルを見つける簡単な方法はありますか?
Class Dependency Analyzerツールが必要です。紹介を引用するには:
このツールの目的は、Java™ クラス ファイルを分析して、これらのクラス間の依存関係について詳しく知ることです。
確かに、実行時の依存関係をキャッチすることはできませんが、網羅的な 100% カバレッジ テスト スイートを実行しない限り、すべての実行時依存関係をキャッチしたことを確認することはできません。
ランタイムの依存関係が予想される場合は、最初のパスとして CDA を使用する必要があります。次に、結果のアプリを徹底的にテストして、ランタイムの依存関係によってのみ参照された jar ファイルがないことを確認します。
「それらを1つずつ削除し、アプリケーションがまだコンパイルされて動作するかどうかを確認する」は、期待される答えではないと思います:)
(編集:上記のアプローチは少し自動化することができますが、それは何とか面倒なままであり、少なくともコンパイル時の依存関係については、代替手段が必要です。グーグルで調べた後、これに適したツールと思われるJar Analyzerを見つけましたこのブログ投稿で説明されているように動作します:
Jar アナライザーは、コンパイルの依存関係をスキャンします。つまり、これらの JAR ファイルをコンパイルするために必要な JAR ファイルをコンパイルするために必要な JAR ファイルなどのツリーを作成できます。すべての JAR ファイルと、それらがそこにある理由を示す非常に優れたレポート/グラフが表示されます。
また、コードに関係のない JAR ファイルを確認し、それらとその子を削除することもできます。libs フォルダーで見つかったのは、libs フォルダー内の 150 個の JAR ファイルの約 20% がコンパイル時に使用されておらず、これらは削除される可能性のある JAR であるということでした。
大きな問題は、検出とリフレクションによって実行時にのみ使用される JAR ファイルに関するヒントが得られないことです。そして、ここからが本当の仕事の始まりです。
JAR ファイルが実行時に使用されているかどうかを確認する唯一の方法は、基本的にそれを取り出してアプリケーションを起動し、すべての機能をテストすることです。中程度のサイズのアプリケーションがある場合、100% 回帰テストを実行するには何時間もかかります。そのため、実際には、多くの推測、迅速で汚いテストを行い、どのランタイム依存関係が実際に使用されているかを調べることになりました。
使い方はとても簡単です。すべての jar を含むディレクトリでツールをダウンロードし、解凍して実行します。または、提供されている Ant タスクを使用します。)
また、実行時にプロジェクトの実際の jar 依存関係を見つけることができるLoosejar.jarもあります。
Eclipse の最新ビルドでは、ソース コード内の未使用のインポートについて警告が表示されます
コンパイラには-verbose
オプションがあり、非常に冗長です。ロードされる各クラスと、どこからロードされるかを通知します!
これはあまりユーザーフレンドリーではなく、高レベルの分析を提供するものではありませんが、クラスパスの競合をデバッグするのに非常に役立つことがわかりました。これは、使用されない jar ではなく、使用される jar を (の助けを借りてgrep
) 示します。
クラスパス ヘルパーを確認する