java - Java コードでパッケージ名前空間の競合を見つけるためのツール

Question

同じまたは類似のパッケージ名を使用するプロジェクトが多数あります。多くの、またはこれらのプロジェクトは、他のプロジェクトで使用される jar ファイルを構築します。foo.util foo.db および foo.exceptions で、同じクラス名が使用されているために名前空間の競合が発生していることが多数発見されました。

Javaコードベースのセットを検索し、名前空間の競合とあいまいなインポートを自動的に見つけるツールを知っている人はいますか?

Answer 1

個々のプロジェクトごとに名前を修正する方が簡単です。

本当。

すべての競合を知る必要はありません。パッケージ名は最初から一意である必要があります。それらが一意でない場合は、パッケージ名の割り当て方法を再考する必要があります。それらが「フラット」(foo.thisおよびfoo.that) である場合は、それらをより高く、より具体的にする必要があります。

That's why the examples are always org.apache.project.component.lower.level.names.

You should have com.projectX.foo.this and com.projectZ.foo.that to prevent the possibility of duplication.

"But all that recompiling," you say. You'll have to do that anyway. Don't waste a lot of time trying to discover the exact, complete extent. Go with what you know, start fixing things now, and work your way through your code base fixing one thing at a time.

Answer 2

プロジェクトを Eclipse にロードできる場合は、[問題] ビューに競合とあいまいなインポートが表示されます。不要なインポートに役立つ、インポートの整理ウィザードもあります。

Answer 3

私は S.Lott に同意します。まず、これがどのように発生したかを突き止め、間違ったことをした人々に非常に苦痛を与える必要があります (つまり、元に戻って問題を修正する必要があります)。最新の IDE (Eclipse はその 1 つです) は、この種のリファクタリングをかなり簡単にします。

私が同意しない唯一のことは、あなたが行くにつれて物事を修正することです. 代わりに、しっかりしたパッケージ名のレビューを行って、今すぐこれに関する技術的負債を支払うことを強くお勧めします. ここで数時間 (実際にはそれだけで十分です) を待てば、今後の悪夢のようなデバッグ作業を避けることができます。

参考までに、異なるソース フォルダーに同じパッケージ内のクラスを含めることは完全に合法です (例):

src/com/my/project テスト/com/my/project

上記の有効なフォルダー構造と、最終的に発生する状況とを区別しようとすることは、自動化された方法では非常に困難になります。