VS CodeでJavaの自動ビルドを止めるには、settings.jsonで java.autobuild.enabled を false にし、ビルドしたいときに Shift+Alt+B(Java: Force Java Compilation)を押します。止めても、編集中のファイルの構文エラー表示とコード補完は保存を待たずに更新されます。止まるのは、自動ビルドによるクラスファイルの出力と、変更の影響を受けた開いていない別ファイルのエラー表示の更新です。
Extension Pack for Javaは、Microsoftが公開しているJava開発用の拡張6本の詰め合わせです。この記事では2026年10月13日時点の構成、言語サーバーが要求するJDK、自動ビルドを止めたときの挙動の検証結果、ビルドが重いときの対処を順に説明します。
まとめ:自動ビルドの停止とExtension Pack for Javaの要点
- 止め方:
"java.autobuild.enabled": false。手動ビルドはShift+Alt+B(macOSはShift+Option+B)です。 - 止めても残るもの:編集中ファイルの構文エラー表示とコード補完。開いたファイルのエラー表示も更新されます。
- 止まるもの:クラスファイルの出力と、開いていない別ファイルへ波及するエラー表示。
- 実行とデバッグ:Debugger for Javaは起動前にビルドする設定が既定で有効なので、自動ビルドを止めても実行前にはビルドされます。
- パックの中身:Red Hatの言語サポート、Debugger、Test Runner、Maven、Gradle、Project Managerの6本です。IntelliCodeは2025年11月に外れ、拡張そのものも非推奨になりました。
- JDK:言語サーバーの起動に使うJDKと、プロジェクトのコンパイルに使うJDKは別に設定します。安定版1.56.0の言語サーバーはJava 21以上で動き、次の1.57.0では25以上に上がります。
- Spring:Spring Boot ToolsなどはこのパックではなくSpring Boot Extension Packに入っています。
Extension Pack for Javaに含まれる6拡張の構成と役割
Extension Pack for Java(拡張ID vscjava.vscode-java-pack)は、拡張を束ねるための入れ物です。言語機能の大半は、Red Hatが開発するLanguage Support for Javaが担います。この拡張は、Eclipseのコンパイラ部品(JDT)で作られたJava言語サーバー(jdtls)を中で起動しています。パックの構成は、GitHubのマニフェスト(package.json)の extensionPack が一次情報です。
6拡張の一覧と2026年10月時点の安定版
| 拡張 | 拡張ID | 安定版 | 担当 |
|---|---|---|---|
| Language Support for Java by Red Hat | redhat.java | 1.56.0 | 補完・エラー表示・自動ビルド |
| Debugger for Java | vscjava.vscode-java-debug | 0.59.0 | 実行・デバッグ |
| Test Runner for Java | vscjava.vscode-java-test | 0.46.0 | JUnit・TestNGの実行 |
| Maven for Java | vscjava.vscode-maven | 0.46.0 | Mavenのゴール実行 |
| Gradle for Java | vscjava.vscode-gradle | 3.18.0 | Gradleのタスク実行 |
| Project Manager for Java | vscjava.vscode-java-dependency | 0.27.6 | プロジェクトと依存の表示 |
安定版はVS Code Marketplaceの公開APIで2026年10月13日に確認した値で、パック本体は0.31.1(2026年6月9日公開)です。表は確認日時点の安定版です。実際にインストールされる版は、VS Codeとの互換性や更新・バージョン固定の設定によって異なる場合があります。
公式ドキュメントと構成が違う理由:GradleとIntelliCodeの入れ替え
検索すると「IntelliCodeが入っている」「Gradleは別に入れる」という説明が今も見つかります。VS Code公式のJava extensionsのページも、2026年10月13日時点でIntelliCodeを6本目に挙げ、Gradle for Javaは別の節で紹介しています。実際の構成は2回変わっています。
- 0.29.0(2024年8月13日):Gradle for Javaがパックに加わりました。
- 0.30.5(2025年11月17日):IntelliCodeがパックから外れました。
どちらもパックの変更履歴に記録があります。IntelliCodeを外す判断と代替機能は、後述のIntelliCodeの節で説明します。
Extension Pack for Javaのインストールと言語サーバー用JDKの設定
Extension Pack for Javaの導入:拡張機能ビューとCLI
拡張機能ビュー(Ctrl+Shift+X)で「Extension Pack for Java」を検索し、発行元がMicrosoftのものを入れます。複数台に同じ環境を作るときは、VS Codeのコマンドラインから入れるほうが確実です。
code --install-extension vscjava.vscode-java-pack
JDKもVS Codeもまだ入っていないWindowsとmacOSでは、JDK・VS Code・拡張を一度に入れるCoding Pack for Javaも使えます。公式のGetting Startedにある通り、Coding PackはWindowsとmacOS向けだけで、LinuxではJDKと拡張を個別に入れます。JDKを複数のバージョンで切り替える場合は、SDKMAN!の使い方|Javaのインストール・切り替えと.sdkmanrc、Windows・macOSの注意点で扱う方法でJDKを入れておくと、後述の java.configuration.runtimes に並べやすくなります。
言語サーバー用のJDK:安定版はJava 21、1.57.0からJava 25
Language Support for Javaには、OSごとの配布版にJREが同梱されています。安定版1.56.0のmacOS(Apple シリコン)向けパッケージを展開すると、Java 21.0.12のJREが入っていました。同梱JREで言語サーバーが起動するので、普通はJDKを別に指定する必要はありません。
注意したいのは次の1.57.0です。Red Hat拡張の変更履歴には「同梱JDKを25 LTSに上げる」とあり、README上の最低要件もJava 21から25に変わりました。GitHub上の1.57.0は2026年9月30日付けでプレリリース扱いで、MarketplaceはこのときまだJava 21の1.56.0を安定版として配っています。
影響を受けるのは、java.jdt.ls.java.home で言語サーバー用のJDKを自分で指定している環境です。ここにJDK 21を書いていると、1.57.0が安定版になった時点で要件を満たさなくなります。特別な理由がなければこの設定を消して同梱JREに任せるか、JDK 25を指定します。
プロジェクト用JDKの登録:java.configuration.runtimes
言語サーバー用とは別に、プロジェクトのコンパイルに使うJDKを登録します。1.56.0が扱えるソースはJava 1.8から26までです。Mavenの maven.compiler.release やGradleのツールチェーンで指定したバージョンに合うJDKが、この一覧から選ばれます。
// ユーザー設定の settings.json
"java.configuration.runtimes": [
{ "name": "JavaSE-17", "path": "/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home" },
{ "name": "JavaSE-21", "path": "/Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home", "default": true }
]
Windowsでは C:\\Program Files\\Java\\jdk-21 のようにバックスラッシュを二重にします。Gradle側でJDKを固定する場合は、ツールチェーン(toolchain)とは?構成要素と言語別の実例・GradleのJava Toolchain設定で扱う languageVersion の指定とバージョンをそろえると、JDKの不一致を減らせます。ただし、言語サーバーのビルドとGradleのビルドでは処理内容が異なるため、最終的なビルドとテストはプロジェクトのGradle Wrapperでも確認します。
VS CodeでJavaの自動ビルドを停止する手順
Language Support for Javaは、ファイルを保存するたびに変更分をコンパイルします(自動ビルド)。既定で有効で、Eclipseの「自動的にビルド」と同じ仕組みです。モジュールの多いプロジェクトでは、保存時のビルド負荷を抑えるために自動ビルドの停止を検討する場合があります。
自動ビルドの停止設定:java.autobuild.enabled
コマンドパレットで「基本設定: ユーザー設定を開く (JSON)」を選び、次の1行を足します。設定画面で java.autobuild と検索し、チェックを外しても同じです。
// settings.json
"java.autobuild.enabled": false
この設定はウィンドウ単位で効くため、特定のリポジトリだけ止めたいときは、そのフォルダの .vscode/settings.json に書きます。設定名と既定値(true)はRed Hat拡張のREADMEの設定一覧で確認できます。
手動でビルドする:Force Java Compilation と Rebuild Projects
止めたあとは、次のコマンドでビルドします。コマンド名は英語のまま表示されます。1.56.0のパッケージに含まれる翻訳ファイルは韓国語と中国語(簡体字・繁体字)だけで、日本語版のVS Codeでもコマンドパレットで「Java: Force」のように英語で探すことになります。
| コマンド | キー | 使う場面 |
|---|---|---|
| Java: Force Java Compilation | Shift+Alt+B | Incrementalで差分、Fullで全体をビルド |
| Java: Rebuild Projects | なし | 選んだプロジェクトを全部作り直す |
| Java: Reload Projects | Shift+Alt+U | pom.xmlやbuild.gradleの変更を反映 |
Force Java Compilationを実行すると「Incremental」と「Full」の選択肢が出ます。Incrementalは変更分だけ、Fullはワークスペース全体をコンパイルします。普段はIncrementalで足り、古いエラーが残るときだけFullを選びます。キー割り当てはmacOS用の別定義がないため、macOSでも Shift+Option+B がそのまま使えます。
自動ビルドを止めると何が変わるか:言語サーバーでの検証結果
「止めると補完やエラー表示が更新されなくなる」という説明をよく見かけますが、検証すると正確ではありませんでした。redhat.java 1.56.0のパッケージから言語サーバー(jdtls 1.61.0)を取り出し、2クラスのMavenプロジェクトを開いて、自動ビルドの有効と無効で同じ操作をしました。VS Codeの画面からではなく、VS Codeと同じ通信手順(LSP)で言語サーバーを直接操作しています。起動にはmacOS(Intel)上のTemurin 25を使いました。
操作は、Greeter.java の greet() を greet2() に改名して保存し、それを呼んでいる App.java がどう扱われるかを見るものです。
| 確認したこと | 有効(既定) | 無効 |
|---|---|---|
| 起動直後のクラスファイル | 作られる | 作られない |
| 保存後のクラスファイル | 約0.5秒で更新 | 更新されない |
| 開いていないApp.javaのエラー | 保存後すぐ表示 | 表示されない |
| App.javaを開いたときのエラー | 表示 | 表示 |
| App.javaでの補完候補 | greet2() | greet2() |
| 未保存の構文エラー | 表示 | 表示 |
| Incremental相当のビルド要求 | 差分なし | 約1秒でビルド |
補完とエラー表示は、ディスク上のクラスファイルではなく、言語サーバーがメモリに持つソースの構造から作られます。今回の検証では、自動ビルドを止めても、編集中のファイルと新たに開いたファイルの補完・診断に変更が反映されました。困るのは2つです。「問題」パネルに出ていない別ファイルのエラーに気づけないことと、target/classes などのクラスファイルが古いまま残ることです。外部ツールがクラスファイルを読む構成(ホットリロードの監視、別ターミナルでの java -cp 実行など)では、手動ビルドを忘れると古いコードが動きます。
Debugger for Javaの起動前ビルドと設定条件
mainメソッドの上の「Run|Debug」や、F5での起動はDebugger for Javaが担当します。この拡張には java.debug.settings.forceBuildBeforeLaunch という設定があり、既定値は true(起動前にワークスペースをビルドする)です。Debugger for Javaのマニフェストで既定値を確認できます。自動ビルドを止めても、この設定が有効なら、Debugger for Javaから起動するたびにビルドが走ります。この設定を false にしている環境では、実行前に手動ビルドが必要です。
ビルドに失敗したときに起動を続けるかは java.debug.settings.onBuildFailureProceed(既定 false)で決まります。true にすると古いクラスのまま動くことがあるので、常用はしません。
ビルドが重い・Activatingのまま終わらないときの対処
自動ビルドを止めるのは最後の手段です。重さの原因が特定のフォルダや設定にあるなら、止めずに直せます。
java.maxConcurrentBuilds の既定値は1
java.maxConcurrentBuilds は同時に走らせるプロジェクトビルドの数で、既定値は 1 です。素の環境ではこれ以上下げられません。値が大きくなる一例は、後述のExtension Pack for Java Auto Configによって未設定の項目が自動設定された環境です。手動設定や共有された設定ファイルによって変わる場合もあります。Auto Configはこの値を論理CPU数に書き換えるので、マルチモジュールのプロジェクトでは同時に実行できるプロジェクトビルド数が増え、CPU負荷が高くなる場合があります。重いと感じたら、ユーザー設定のこの値を 1 に戻すと同時に走るビルドを1つに抑えられます。
Javaの読み込み停滞:ビルド状況・ログ・キャッシュの切り分け
ステータスバーのJava表示が読み込み中のまま進まないときは、次の順に見ます。
- Java: Show Build Job Status:今どのジョブ(Mavenの依存解決、Gradleのインポートなど)で止まっているかを表示します。初回はGradle Wrapperや依存ライブラリのダウンロードで数分かかることがあります。
- Java: Open Java Language Server Log File:起動に使うJDKが要件を満たさない、メモリが足りないといったエラーはここに出ます。言語サーバーの最大メモリは
java.jdt.ls.vmargsの既定で-Xmx2Gです。 - java.import.exclusions:既定で
node_modulesなどを除外しています。生成コードや巨大なサンプルのフォルダをここに足すと、インポートの対象が減ります。 - Java: Clean Java Language Server Workspace:言語サーバーのキャッシュを消して作り直します。古いエラーが消えない、ビルド表示が回り続けるといった壊れ方に効きます。再起動後は全体のインポートからやり直すので、最初の起動は遅くなります。
コード閲覧用のLightWeightモードと機能制限
java.server.launchMode を LightWeight にすると、依存関係を解決せず、ソースとJDKだけを対象に構文の機能(アウトライン、移動、構文エラー)を提供します。公式ドキュメントのLightweight Modeにある通り、このモードでは実行・デバッグ・リファクタリング・意味的なエラー検出が使えません。レビューのために大きなリポジトリを開くだけなら、ビルドが一切走らないこのモードのほうが向いています。既定の Hybrid は、まず軽いモードで開き、未解決のJavaプロジェクトがある場合は通常のモードへの切り替えを確認します。「Later」を選ぶと軽いモードにとどまります。
Extension Pack for Java Auto Config(Pleiades)との違い
名前がよく似た「Extension Pack for Java Auto Config」(拡張ID Pleiades.java-extension-pack-jdk)は、MicrosoftではなくPleiadesが公開している別の拡張です。中身はMicrosoftのExtension Pack for Javaを含む上位の詰め合わせで、2026年6月24日公開の2026.624.0のマニフェストでは、Spring Boot Extension Pack、Red HatのXML拡張、スペルチェッカー、Live Serverなど計8本をまとめて入れます。
違いは名前の通り「自動設定」にあります。Auto ConfigのREADMEによると、次のことを起動時に自動で行います。
- JDKが見つからなければAdoptiumの最新LTSを3バージョン、GradleとMavenの最新版をダウンロードする(
extensions.autoUpdateがfalseでない場合) - 見つけたJDKを
java.configuration.runtimesに登録し、壊れたパス指定を直す - 未設定の項目をユーザー設定に書き込む:
java.maxConcurrentBuildsを論理CPU数、java.configuration.updateBuildConfigurationをautomatic、デバッグ中のコード差し替え(java.debug.settings.hotCodeReplace)をautoにするなど
JDKの準備から始める学習用の環境なら、Auto Configのほうが早く動きます。チームでJDKや設定を管理している環境では、ユーザー設定を自動で書き換えられると人によって挙動が変わるので、Microsoftのパックだけを入れるか、javaAutoConfig.enabled を false にします。
Maven・Gradle・Project Manager for Javaの使い方
Project Manager for Java:Java Projectsビュー
エクスプローラーに「Java Projects」ビューが加わり、プロジェクト・パッケージ・依存ライブラリをツリーで確認できます。新規作成はコマンドパレットの「Java: Create Java Project…」で、プロジェクトの種類を選ぶと必要な拡張の導入も案内されます。ビルドツールを使わないプロジェクトでも、Referenced LibrariesにJARを追加すれば外部ライブラリを参照できます。
Maven for Java:使われる mvn の決まり方
pom.xmlを開くと「Maven」ビューにライフサイクル(clean・compile・test・package など)とプラグインのゴールが並び、クリックで実行できます。どの mvn が使われるかは2つの設定で決まります。
maven.executable.path:空(既定)なら、次の設定に従ってmvnwかmvnを使うmaven.executable.preferMavenWrapper:既定true。親フォルダをさかのぼってmvnwを探し、なければPATH上のmvnを使う
社内リポジトリ用の設定ファイルを使う場合は、maven.settingsFile(既定は ~/.m2/settings.xml)に絶対パスで指定します。
Gradle for Java:インポートに使うJDK
Gradleビューでタスクの一覧と実行ができます。プロジェクトの読み込みでは既定でGradle Wrapperが使われ、Gradle自体を動かすJDKは java.import.gradle.java.home で指定します。古いWrapperは新しいJDKで動かないことがあるので、読み込みに失敗したら gradle/wrapper/gradle-wrapper.properties のバージョンから確認します。
デバッグ・テスト・Lint・AI補完の担当拡張
Debugger for JavaとTest Runner for Javaの実行機能
ブレークポイント、条件付きブレークポイント、変数とウォッチ式の確認に対応します。デバッグ中にメソッドの中身を書き換えて反映するホットコードリプレースは、既定が manual(ツールバーのボタンで反映)です。java.debug.settings.hotCodeReplace を auto にすると、公式ドキュメントの説明どおりコンパイルの後に自動で反映されます。テストはテストエクスプローラーから、JUnitとTestNGを1件ずつでもまとめてでも実行・デバッグできます。
Lintはパックに入っていない:Checkstyle・SonarQube for IDE
パックで出るのは言語サーバーのコンパイルエラーと警告までで、コーディング規約のチェック(Lint)は別の拡張で足します。よく名前が挙がるCheckstyle for Javaは、最後の更新が2023年3月29日の1.4.2で止まっています。2026年10月時点で更新が続いているのは、SonarSourceのSonarQube for IDE(旧SonarLint、拡張ID SonarSource.sonarlint-vscode、Marketplaceでは10月12日に6.1.0を公開)です。ツールの選び方の全体像は静的解析とは?実行せずに欠陥を見つける仕組みとツールの選び方で比較しています。
IntelliCodeは非推奨:補完は言語サーバー、AIはGitHub Copilotへ
MicrosoftはIntelliCodeのリポジトリで、VS Code向けIntelliCode拡張の非推奨化を告知しています。新機能の追加も不具合の修正も終わり、アンインストールを勧めています。IntelliCodeを外しても、言語サーバーによる通常の補完はそのまま使えます。AIによるコード生成が必要なら、告知が勧めている通りGitHub Copilotを入れます。料金の区分はGitHub Copilotの料金(pricing)|AI Credits移行後のプラン比較とBilling APIでの使用量集計【2026年10月】にまとめています。
Spring Boot開発に必要なSpring Boot Extension Pack
Spring Boot Tools、Spring Initializr Java Support、Spring Boot Dashboardの3本は、Extension Pack for Javaには入っていません。VMware(現Broadcom)が公開しているSpring Boot Extension Pack(vmware.vscode-boot-dev-pack 0.2.2)にまとまっています。Spring Bootを開発するなら両方のパックを入れます。application.propertiesの補完やBeanの移動はSpring Boot Toolsの機能なので、Java Packだけでは使えません。
Spring Boot本体のバージョンごとの違いはSpring Boot 4とは?最新バージョン4.1の変更点・新機能とSpring Boot 3との違いを解説【2026年最新】で扱っています。IntelliJ IDEAやEclipseとの比較はIntelliJ IDEAとEclipseの違いを比較|無料版の範囲・Spring・コンパイル・移行手順【2026年版】を参照してください。Javaでの業務システムを開発環境の選定から外部に任せたい場合は、一創のフルスクラッチ開発でも相談を受けています。
よくある質問
VS CodeでJavaの自動ビルドを止めるには?
settings.jsonに "java.autobuild.enabled": false を書きます。以後は Shift+Alt+B(Java: Force Java Compilation)でビルドします。補完と編集中ファイルのエラー表示は止めても更新されますが、開いていない別ファイルのエラーとクラスファイルは手動ビルドまで更新されません。
Extension Pack for Javaとは何で、何が入っていますか?
MicrosoftがVS Code向けに公開しているJava開発用の拡張パックです。Language Support for Java by Red Hat、Debugger for Java、Test Runner for Java、Maven for Java、Gradle for Java、Project Manager for Javaの6本が入ります。IntelliCodeは0.30.5(2025年11月)で外れました。
Extension Pack for Java Auto Configとの違いは?
Auto ConfigはPleiadesが公開している別の拡張で、Microsoftのパックに加えてSpring Boot Extension Packなどを含み、JDK・Gradle・Mavenのダウンロードとユーザー設定の書き換えを自動で行います。設定を自分で管理したい場合はMicrosoftのパックだけを入れます。
Java: Clean Java Language Server Workspaceは何をしますか?
言語サーバーが保存しているワークスペースのキャッシュを削除し、VS Codeを再読み込みしてプロジェクトを最初からインポートし直します。ソースコードや設定ファイルは消えません。直したはずのエラーが消えない、ビルド表示が回り続けるときに使います。
Spring Initializr Java Supportは含まれますか?
含まれません。Spring Initializr Java SupportはSpring Boot ToolsやSpring Boot Dashboardと一緒に、Spring Boot Extension Packに入っています。Springのプロジェクトを作るなら、Extension Pack for Javaとあわせて入れます。