eclipse備忘録

ソースコード操作
デバッグ
ビューの設定
ファイル操作
1. ファイル検索
全体設定系
Appendix
1. ワークスペースはどこ？
インシデント

ソースコード操作

行削除

Ctrl + D

行複製

Ctrl + Alt + ↓

メソッドの実装を開く

Ctrlを押しながらメソッドをクリック

または

クラスを右クリック> 型階層を開く

文字の拡大・縮小

拡大：Ctrl + 『+』
縮小：Ctrl + 『-』

ペイン分割

Ctrl + [

見ていた場所に戻る

Alt + ←

同じ変数をハイライト

ウィンドウ>設定> Javaエディタ出現カ所のマーク>チェックボックスをON

インデントフォーマット

インデントを自動で整理してくれる。

Eclipse KeyMapというプラグインを導入してから、以下のコマンドで実行する。

Alt + Shift + F

デバッグ

デバッグ実行

プロジェクトを右クリック> デバッグ> Springで実行

テストカバレッジ確認方法

テストコードのファイルを右クリック> カバレッジ

デバッグで値の変更

ブレークポイントで停止したら

ウィンドウ>ビューの表示>変数

ココで値を書き換えることができる

例外を発生させる

例外を発生させたいタイミングでブレークポイントで止める

ウィンドウ>ビューの表示>デバッグシェル

シェルが開いたら、以下を参考に、発生させたい例外を記述。

throw new Exception();

シェルに記載したテキストを選択して右クリック> 実行

※ブレークポイントの処理前に例外が発生する点に注意すること

ビューの設定

コンソールログを折り返す

ウィンドウ > 設定 > 実行/デバッグ> コンソール>ワード・ラップを使用可能にする

編集中のファイルと、サイドバーで選択中のファイルをリンク

ファイルの編集画面を触ると、同じファイルがサイドバーでも自動的に選択される機能。便利だったり、不便だったりする。

左上の左右矢印アイコンでオンオフを切り替えることができる

複数のコンソールビューを開く

コンソールタブの小さなアイコンの中から以下を探して操作する

『コンソールを開く』 > 『新規コンソールビュー』

表示したいプロジェクトを選択した状態で、『選択されたコンソールの表示』

ディレクトリのネストが深すぎる

プロジェクトエクスプローラーになっていると、ドメインまで表示されるためネストが深く、扱いづらい。以下の手順で、パッケージエクスプローラーに変更する。

ウィンドウ＞ビューの表示＞パッケージエクスプローラー

ビルドエラーの確認

ウィンドウ>ビューの表示>問題

ファイル操作

閲覧中のファイルがサイドバーのプロジェクト・エクスプローラーで自動選択されない

プロジェクト・エクスプローラーの場合は機能しないので、パッケージ・エクスプローラーに変更する。

ウィンドウ>ビューの表示> その他>ダイアログが開く

Java パッケージ・エクスプローラーを選択

ファイル検索

Ctrl + H ＞Java検索タブ

検索: タイプ
制限: すべての出現ヵ所 ※宣言にして、検索文字列から拡張子を削除した方が良いかも
次を検索アプリケーションライブラリ

またはCtrl+Shift+R

全体設定系

バージョン確認

ヘルプ＞Eclipse IDEについて

以下のような表記で表示される。

2024-03 (4.31.0)

Eclipseは年に4回 (3月、6月、9月、12月) リリースされる。4.31.0は内部バージョン番号。

色テーマの変更

ウィンドウ > 設定 > 一般 > 「外観」をクリック。好きなテーマを選択する。

明るくするなら、ルック&フィールをライトに変更

キャッシュクリア

プロジェクト> クリーン

Eclipseが重い

下の方にある800Mといった数字を増やして、Eclipseメモリ増やす。

デバッグモードの起動が遅い場合は、ブレークポイントが大量に設定されたまま残っていないか確認する。

日本語化

Pleiades All in One ダウンロードから

『Pleiades プラグイン・ダウンロード』エリアのWindowsを選択

ファイルをダウンロードしたら、解凍する。

pleiadesの中にeclipseというフォルダがあるので配下のfeatures、plubinsの2フォルダを、eclipse側のフォルダ内にコピーする。（結構時間がかかる）

eclipse.iniの末尾に以下2行を追記する。

-Xverify:none
-javaagent:plugins/jp.sourceforge.mergedoc.pleiades/pleiades.jar

pleaiadesではそもそも日本語化済みのeclipseを配布しているので、本当はこれをインストールした方が早い。

プラグインがインストールされたかの確認

ヘルプ＞Eclipse マーケットプレイス＞『インストール済み』タブ

Appendix

ワークスペースはどこ？

起動するときにワークスペースを指定するが、『…workspace』となっていて、どこのフォルダを参照しているのかわからない。

基本的には、以下のようなパスに存在する。

C:\pleiades\2025-06\workspace

ワークスペースの場所は、以下の方法で確認できる。

「ファイル」→「ワークスペースの切り替え」＞「その他」

新しいワークスペースを指定するポップアップが表示されるが、このポップアップの中に、現在のワークスペースの絶対パスも表示される。

インシデント

ビルド時にJAVA_HOMEエラー

エラーメッセージ

ERROR: JAVA_HOME is set to an invalid directory: C:\Program Files\Java\jdk

eclipseをFull Editionで入れなおしたらエラーが出るようになった。

環境変数のエラー。JDKのパスが複数通っていたので、JAVA_HOMEのキーで登録しているもの以外を削除。

コマンドプロンプトを再起動して再ビルド試したら解消。

Eclipse起動時に落ちる

メモリ不足等で起動できない場合は、コマンドプロンプトで実行ファイルの格納先まで移動し、起動オプション付きで手動起動する。

eclipsec.exe -debug -consoleLog

-debug：詳細なデバッグログ出力を有効化する。Eclipseは内部のエラーハンドリング処理を強化モードで動かすようになる。通常モードだと「例外が握りつぶされてそのままJVM が終了」してしまうケースでも、ログ出力や例外処理のコードが有効になり、強制終了せずに動作が継続する場合がある。

-consoleLog：GUIだけでなく標準出力（コンソール）にもログを出すようになる。プラグインの初期化エラーなど、GUI上では無視されるエラーがコンソールに表示される。これにより「見えないまま JVMが落ちる」状況を回避できることがある。

エディタのエラーが解消しない

ソースコードのエラーを修正しても、×マークが消えないとき。

キャッシュの関係なのかわからないが、とりあえずそのままアプリケーションを実行すれば解消する。

エントリーポイントからアプリケーションを実行できない

通常、Eclipse でアプリケーションを起動する場合、以下の手順で行う。

アプリケーションを右クリック＞実行＞Spring Boot アプリケーション

しかし、このとき『実行』オプションが表示されなくなることがある。

また、サイドバーのパッケージ・エクスプローラーでフォルダ階層が認識されず、1つずつフォルダを開いていかなくてはならなくなるような症状も併発する。

これらの症状はプロジェクトがeclipseに認識されないことが原因。

eclipseの設定を管理している『.project』や、『.classpath』といったファイルが作成されていないか、壊れている可能性が高い。

解消方法

とりあえず以下を実行する。

gradlew

単純に未ビルドの場合はこれで.projectが作成される。また、壊れている場合も復旧できる可能性がある。

ダメなら次に、eclipse設定ファイルを生成するコマンドを実行してみる。

gradlew.bat eclipse

このあたりをごにょごにょやってみてダメなら結構厳しい。深堀もできるが、プロジェクト自体のエラーではなく、eclipseの問題なので、ここにそんなに時間をかけてもなぁ、という感じ。

あとは以下のようなことを試す。

.projectと.classpathを削除してgradlew再実行
すでに他のビルド成功しているプロジェクトがあればそこからコピーして、自身のプロジェクト用に改変する
ローカルのプロジェクトを削除して、リモートブランチからクローンしなおす

「必要なプロジェクトでエラー」

実行しようとすると『必要なプロジェクトでエラー』と表示されるが、ファイルにエラーは表示されていない。

この手の、どこでエラーが起きているかわからないエラーが一番タチが悪い。

だが、この場合、大抵はビルド過程でeclipse自体の設定に起因する何らかのエラーが発生しており、確認できるビューがある。

「ウィンドウ」＞「ビューの表示」＞「問題」を開くと、どこでエラーが発生しているかを確認できる。

確認したところ、以下のエラーが発生していた。

ビルド・パスは、重複したエントリーを含んでいます。
プロジェクト 'XXX' の 'src/main/java' が複数回指定されています。

エラー内容から『.classpath』ファイルを直接開いて確認したところ、確かに src/main/java を指定している classpathEntry が重複して存在していた。

classpath が壊れているようである。

Eclipse はこれにより、どちらをエントリーポイントとして扱うべきか判断できず、エラーを起こしていた。

classpath は Eclipse 自身の管理用ファイルであるため、これを修正してもプロジェクト自体が壊れることはない。

classpath を削除して gradlew を再実行するだけでも解消する可能性はあるが、せっかくなので、仕組みの理解のため、以下の手順で対応する。

修正方法詳細

プロジェクトを右クリック＞「ビルド・パス」＞「ビルド・パスの構成」

「順序およびエクスポート」タブを確認すると、src/main/java が複数回読み込まれていた。

他にも、重複して読み込まれているリソースが存在していた。

「ソース」タブに移動し、重複しているエントリーを削除＞「適用」＞「閉じる」

バグなのかわからないが、僕がこれを実行したときは、重複分だけでなく元のリソースまで削除された。適用後は再度ソースタブを開き内容を確認することをおすすめする。

削除されていた場合は、「ソース」タブから改めて src/main/java を追加し、問題が解消した。

ymlファイルを修正しようとするとフリーズする

ymlファイルを開き、修正を少しでも加えると、フッターに以下のメッセージが表示されてフリーズする。

言語サーバー"●●言語サーバー"初期化中

言語サーバーとは、eclipseがコード補完・構文チェック・リファクタリング支援などを行う仕組み。

ウィンドウ＞設定＞サイドバーの『言語サーバー』

エラーメッセージから、エラーを起こしている言語のチェックを外すことで解消する。今回はYAMLのチェックを外して解消した。

これにより、先のコーディングサポートが受けられなくなるが、そこまで影響は無いと思う。

アプリケーションを再起動したらポートが既に使用されている

アプリケーションを起動した状態でeclipseが落ちた。再起動すると、先ほどまで起動できていたアプリケーションが、ポートが既に使用済みとのことでエラーになる。

eclipseがクラッシュしたために、タスクがクローズされず残ってしまっているので、パワーシェルなどで以下の手順を確認し、残ってしまっているプロセスをキルする。

まずは8080ポートに使用されているプロセスのPIDを調べる。

netstat -ano | findstr :8080  //8080の部分は、件のポート番号を指定する

すると以下のようなレコードが見つかる。

TCP    0.0.0.0:8080    0.0.0.0:0    LISTENING    20384  //PIDは20384

次に、このPIDが何のタスクかを調べる。

tasklist /FI "PID eq 20384"

すると、以下のようなレコードが見つかった。

イメージ名    PID      セッション名    セッション#    メモリ使用量
======================================
javaw.exe     20384  Console           1                  123,456 K

javaw.exeは、eclipseなど、IDEからサーバーを起動した際に使用されるアプリケーション。

これでeclipseのクラッシュによって残ってしまったプロセスであることがほぼ確定なので、このプロセスをキルする。

taskkill /PID 20384 /F

無事、アプリケーションが再起動できた。

EntryPointを検出できない

SpringBoot&gradleプロジェクトを起動しようとすると以下のエラー

メイン・クラス xxx.xxx.EntryPoint を検出およびロードできませんでした。

プロジェクト＞クリーンでキャッシュクリアしても、gradlewで再ビルドしても解消しない。

gradleでは、gradlewビルドすると以下の処理が行われる。

/buildフォルダが作成される
配下にJavaファイルをコンパイルしたクラス（.javaで作成していたファイルたちが.class拡張子になる）が格納される（/build/classes配下）
クラスパス（上記のクラスをどこに格納したか示すパス）が登録される …※
アプリケーションは、クラスパス配下のEntryPoint.classを探しに行く

※本来はクラスパスを登録する指定が必要だが、eclipseでプロジェクトをビルドしていれば、クラスパスは自動で登録される。
この設定は.classpathファイルで指定されている。
gradleの場合は/build/classes/java/mainがクラスパスになる。

前置きが長くなったが、buildが失敗して、classesクラスが生成されていなかったりすると、上記のエラーが起きる。

再ビルドすると大抵は解消する。

あとは、eclipseではなく、パワーシェルなどのコンソールから、gradlew bootRunで起動してみると動いたりする。