回答:
インポートを削除しない場合は、パフォーマンスの問題などは起こりそうにないと思います。
ただし、まれにリストインターフェースのインポートなど、名前の競合が発生する可能性があります。
Eclipseでは、常にショートカットを使用して（OSによって異なります-Win：Ctrl + SHIFT + OおよびMac：）COMMAND + SHIFT + O、インポートを整理できます。次に、Eclipseはインポートセクションをクリーンアップして、古いインポートなどをすべて削除します。インポートされたものが再び必要な場合、Eclipseは、でステートメントを完了している間、それらを自動的に追加しますCtrl + SPACE。したがって、クラスで未使用のコードを保持する必要はありません。
いつも未使用のコードは、コードを読んでアクティブなコードに何かを残している間、あなたや他の人の注意をそらすので、後で必要になるかもしれないため、たいていは悪い習慣と見なされます。
ctrl+3にアクセスする別の方法は、（少なくともwindwosで）クリックしてからインポートと入力することです。Ctrl + Shift + Oよりも明らかに遅いですが、特定のショートカットを覚えていなくても、すばやく見つける方法（および覚えているか、見つけようとしている他の多くのアクション）です。
1つは、インポートによって参照されるクラスをクラスパスから削除した場合、目的を果たさない愚かなコンパイラエラーが発生しないことです。また、「使用場所」検索を実行しても、誤検知は発生しません。
もう1つ（ただし、これは性質上非常に固有です）は、未使用のインポートが別のインポートと名前の競合を引き起こし、完全修飾名を不必要に使用してしまう場合です。
補遺：今日、ビルドサーバーはメモリ不足エラーでコンパイルに失敗し始めました（テスト実行すらされていません）。これはいつまでも問題なく実行され、チェックインにはビルドプロセスの変更や、これを説明できる重要な追加はありませんでした。メモリ設定（これは64ビットのCentOSで64ビットのJVMを実行しています）をクライアントがコンパイルできる場所をはるかに超えて増やした後、チェックインを1つずつ調べました。
開発者が使用して放棄した不適切なインポートがありました（クラスを使用し、自動インポートして、それが間違いであることに気付きました）。その未使用のインポートは、アプリケーションの完全に別の層を引き出しましたが、IDEはそれらを分離するように構成されていませんが、ビルドプロセスはそうです。その単一のインポートが非常に多くのクラスにドラッグされたため、コンパイラーは、クラスパスに関連する依存ライブラリーを持たずにコンパイルしようとしました。これにより、メモリ不足エラーの原因となる多くの問題が発生しました。未使用のインポートによって引き起こされるこの問題を解決するのに1時間かかりました。
純粋な観点から見ると、依存関係は製品に対する「制約」であり、後でメンテナンスの問題を引き起こす可能性があります。
たとえば、プログラムがcom.XYZObjectPoolクラスを使用していて、後でそれを使用しないことに決めたが、インポートは削除しないと仮定します。他の誰かがorg.WVYObjectPoolをインスタンス化してObjectPoolを参照するだけの場合、キャストの問題または呼び出しの問題が発生するまで、警告は表示されません。
ところで、これは非現実的なシナリオではありません。EclipseにインポートするXの特定のバージョンを尋ねるたびに、多くのパッケージから1つを選択しましたが、そこにインポートしたことがある場合、知らないうちに間違った選択をした可能性があります。
どちらの方法でも、Eclipseにこれらのクリーンアップを依頼できます
警告？Eclipseに自動的にクリーンアップするよう依頼してください。これがIntelliJの機能です。あなたに警告するのに十分賢いなら、それはそれらを片付けるのに十分賢いはずです。私はEclipseの設定を探すことをお勧めします。これにより、そんなつまらないことをやめて何かをするように指示できます。
これは、メンテナンスに役立つプログラムの明確さに関係しています。
プログラムを保守する必要がある場合は、1行に1つのクラスをインポートすると便利です。
次のシナリオについて考えてみます。
import company.billing.*;
import company.humanrerources.*;
// other imports
class SomeClass {
// hundreds or thousands of lines here...
public void veryImportantMethod() {
Customer customer;
Employee comployee;
Department dept.
// do something with them
}
}コードの一部をバグ修正または保守している（またはコードを読んでいるだけの）場合、使用するクラスがどのパッケージに属しているかを読者が知ることは非常に役立ちます。上記のようにワイルドカードインポートを使用しても、その目的には役立ちません。
IDEを使用している場合でも、ホバーしたり宣言にジャンプしたりしたくない場合は、現在のコードが依存している他のパッケージやクラスを機能の観点から理解すると簡単です。
これが個人的なプロジェクトや小さなプロジェクトの場合、それは本当に問題ではありませんが、他の開発者が使用する必要がある（そして何年にもわたって維持される）大きなプロジェクトの場合、これは必須です。
パフォーマンスの違いはまったくありません。
参考までに、これは私を見つけました、インポートを整理することは実際に未使用のインポートを削除するとは思わなかったので、単にそれらをソートしたと思いました。
保存操作中にインポートを自動的に削除すると、たとえば開発中またはテスト中に問題が発生してコードをコメントアウトしたときに、いくつかの悲しみを引き起こしました。保存すると、コードのコメントアウトされたセクションで使用されているインポートが削除されます。変更を元に戻す（Ctrl+ Z）ことができるため、これは問題にならない場合がありますが、他の変更を行った場合ほど簡単ではありません。また、コードのコメントを解除すると（以前にコメントアウトして保存したため、そのコードのインポートを削除しました）、必要なインポートを自動的に推測し、間違ったものをピックアップしました（たとえば、StringUtilsクラスが使用されていて、間違ったライブラリから同じ名前の別のクラスが選択されていました）。
インポートを保存アクションとしてではなく、手動で整理することを好みます。
何年か前に、インポートされたすべてのクラスが実行時にインポートされたクラスでロードされることをどこかで読みました。したがって、未使用のパッケージ、特にパッケージ全体を削除すると、メモリのオーバーヘッドが減少します。私はJavaの最新バージョンがそれを処理すると思いますが、おそらくそれはもう理由ではありません。
ところで、EclipseではCtrl+ Shift+ Oを使用してインポートを整理できますが、Javaファイルを保存するたびに、そのようなこと（およびその他多くのこと）を処理する「クリーナー」を構成することもできます。
私にとって、コードのクリーンアップ中にインポートされたクラスを削除し、ローカルでビルドをテストせずにgitで削除をコミットした後、コントローラークラスの未使用のクラスインポートによってJenkinsビルドでコンパイルの問題が発生しました。