例外で終了するパッケージがあります。
package a.b.c.exception;
私たちのコードベースはEclipse3.3まで問題はありませんでしたが、Eclipse 3.4に移行すると、このパッケージに関連するエラーが発生し始めました。
"The package a.b.c.exception collides with a type"
パッケージ名をabcexceptionsにリファクタリングしても、問題はありません。これはEclipse3.4のバグによるものですか、それともこの動作を修正するための設定がありますか？
exceptionこれは、パッケージに（小文字の「e」が付いた）という名前のクラスとa.b.c、という名前のパッケージがあるためa.b.c.exceptionです。
あなたがコードを持っているなら、それはあなたがクラスの静的メソッドa.b.c.exception.doSomething();を呼び出したいということを意味するので、それは名前の衝突を引き起こしますか？それとも、のコンストラクターを呼び出そうとしているというクラスがあるということですか？doSomething()a.b.c.exceptiona.b.c.exception.doSomething
Javaの命名規則（すべて小文字、大文字で始まるクラス、その後のキャメルケースをパッケージ化する）に固執すれば、この問題は発生しません。
==========編集==========
これが、このエラーが表示される唯一の正当な理由です...
プロジェクトに直接存在する必要はありません。プロジェクトが依存している別のプロジェクトまたはライブラリに存在する可能性があります。これにより、ビルドパスまたはプロジェクトの任意の場所にクラスが出現することが表示されます。Eclipseツールバーの懐中電灯検索ボタンを押します->[Java検索]を選択します->検索フィールドにabcexceptionを入力します->[大文字と小文字を区別します]を選択します-> 「検索対象」で「タイプ」を選択します->「検索対象」ですべてのオプションが選択されていることを確認します。
クラスを生成するツールを使用していますか？彼らはそれらをあなたのプロジェクトのビルドディレクトリに入れているのでしょうか？エラーが表示されたときに、プロジェクトのビルドディレクトリに移動し、a / b / c /ディレクトリに移動すると、「例外」の.classファイルが表示されますか？
もちろん、Eclipseには一般的にバグがある可能性があります（ただし、Eclipse 3.4にはバグレポートがあり、それがあればさらに多くの苦情を見つけることができると思います...）、Eclipseのインストールが一部で壊れている可能性があります方法（他の誰かがEclipse 3.4でプロジェクトを開くことができますか？別のディレクトリにEclipse 3.4をクリーンインストールできますか？エラーがそこに表示されますか？）、またはプロジェクトが何らかの方法で混乱する可能性があります（依存関係のない新しいプロジェクトを作成します） JDK以外の場合は、新しいプロジェクトにabcexceptionパッケージを作成し、プロジェクトにクラスを作成してimport a.b.c.exception.*;、エラーが発生するかどうかを確認します。）
Javaでは、パッケージ名と同じクラス名を持つことはできません。
つまり、JDTパッケージは3.4でのみそのルールを適用している必要があります
たとえば、バグ63668を参照してください。
ネイトがコメントするように：
Exceptionという名前のクラスは、パッケージ例外の作成を妨げることはありません。
ケースが重要です。また、クラスのフルネームには、そのクラスが含まれるパッケージが含まれていることを忘れないでください。
したがって、（クラス名）は（パッケージ名a.b.SomeClass）とは異なります。 ここでは名前の衝突はありません。x.y.SomeClassこのエラーを発生させるには、クラス名とパッケージ名が大文字と小文字の両方で一致している必要があります。
彼のより正確な答えを参照してください。
継承した巨大なコードベースで同様の問題が発生しました。衝突は、JavaDocリンクの部分的に修飾されたクラス名が原因であることが判明しました。
言い換えると、Eclipseは、abcdLondonをコンパイルするときにabcdのパッケージ/タイプの衝突が発生したと言っていました。abcdのコードでJava検索を実行すると、EclipseはabcParisのJavaDocコメントが一致すると考えていることがわかりました。JavaDocコメントには{@linkd.NewYork}が含まれていました。{@link abcdNewYork}を読み取るように変更すると、コンパイルエラーが解決されました。
NewYorkは、JavaDocコメントにのみ表示されるため、Parisクラスにインポートされなかったことにも注意してください。これにより、省略形で未解決になり、コメント内のリンクをクリックしても機能しませんでした。絶対参照にすることで、JavaDocリンクも機能します。
私はこれがばかげているように聞こえ、おそらく真実には単純すぎることを知っていますが、私はこれとまったく同じエラーメッセージを次のように解決しました：
なぜこれが機能したのかはわかりませんが、機能し、Eclipseはその場でタントラムを投げることをやめました。
安全なタイピングとスピーディーなコーディング。
-Goodge
eclipseのコンパイルオプションの1つを変更すると、問題は解消されました。ワークスペースのプロパティの下：Javaコンパイラ->エラー/警告->「未使用のインポート」を「警告」から「無視」に変更します。
クラスFooがある場合、com.my.FooのようにFooで終わるパッケージを作成することはできません。
また、Mavenスタイルを使用している場合は、プロジェクト内にsrc / main / resourcesなど
のリソースがあります。リソース内のフォルダーにもパッケージスタイルがあり、クラスの名前を含むフォルダーを作成することはできません。
推奨される規則に従ってJenkinsプラグインを開発すると、この問題が確実に発生します。
Jenkinsの規則に従い、パッケージxyのMyBuilderという名前のクラスにビルダーを作成する場合は、.jellyをxyMyBuilderという名前のリソースフォルダーに配置することもできます。これにより、上記の問題が発生します。
ただし、リソースフォルダーにxymyBuilderという名前を付けると（myBuilderでは小文字の「m」に注意）、推奨される規則とは異なり、プラグインは意図したとおりに機能します。