java インストール決定版：JDK/Win/Mac/Linux

SHARE

SQL Developerの導入をWindows/Mac/Linux別に解説。JDKの確認・インストールとPATH設定、SQL Developerのインストール/削除、旧設定の移行、対応DBとJDBC高度セキュリティ、アクセシビリティ(JAB含む)まで網羅、動作保証と公式ドキュメントも案内。

目次

Java/JDKのインストール概要

java+jdk+installation

これからJava環境を整える方に向けて、「何を入れればよいのか」「どのOSで動くのか」「どのバージョンを選ぶべきか」というjava インストール時の核心ポイントを短時間で把握できるように整理します。まずはJDKとJREの違い、対応OSと一般的な要件、そしてLTSと最新版の選び方という3つの観点から全体像を押さえましょう。

JDKとJREの違いと用途

Javaの配布物には大きく「JDK」と「JRE」があります。結論から言えば、開発はもちろん運用でもJDKを入れておけば困ることはほぼありません。特にJava 11以降は、JRE単体の配布が縮小された経緯があるため、java インストールの基本はJDKです。

項目 JDK（Java Development Kit） JRE（Java Runtime Environment）
主な用途 開発・ビルド・デバッグ・実行 実行のみ
含まれるツール javac（コンパイラ）、java（実行）、jshell、javadoc、jar、jlink、jpackage、keytool など java（実行）と最小限のランタイム
適するケース 開発マシン、CI/CD、運用でのトラブルシュートやツール利用 エンドユーザー実行専用の最小構成が必要な場合
  • 学習・開発者: JDK一択。コンパイルやドキュメント生成、対話型のjshellなどが使えます。
  • 本番運用: 近年はJDKを導入するか、JDKのjlinkで作る最小ランタイムを用いるのが主流です。
  • 配布アプリ: ベンダーが同梱ランタイムを提供している場合は、その指示に従います。

対応OSと必要システム要件

JDKは主要OSを広くサポートしますが、ディストリビューション（Oracle、Eclipse Temurin、Amazon Corretto、Microsoft Build of OpenJDK など）ごとに対応範囲が異なることがあります。java インストール前に配布元のサポート表を確認しましょう。

  • 対応OSの目安
    • Windows: Windows 10/11、Windows Server 系の現行世代
    • macOS: Intel（x64）およびApple Silicon（arm64）対応の現行リリース
    • Linux: Ubuntu LTS、Debian、RHEL系（RHEL/AlmaLinux/Rocky）、SUSE系など主要ディストリビューション
  • CPUアーキテクチャ
    • x64（x86_64）が標準。近年はarm64（AArch64）にも広く対応
  • メモリ・ディスクの一般的な目安
    • メモリ: 最低2GB程度で動作可能。快適な開発用途では8GB以上を推奨
    • ディスク: JDK本体は数百MB規模。ビルドキャッシュや依存ライブラリで数GB以上になることが多い
  • その他
    • ビルドや依存取得のためのネットワーク接続
    • 企業環境ではプロキシ設定が必要な場合あり

同じメジャーバージョンでもOSのサポート期間やCPU最適化は配布元により差があります。長期運用や大規模導入では、採用するJDKベンダーのサポートポリシーおよび対応プラットフォームを事前確認してください。

LTSと最新版の選び方

Javaは半年ごとに新機能リリースがあり、その中で長期サポート（LTS）版が定期的に提供されます。代表的なLTSはJava 11、17、21です。どれを入れるか迷ったら、まずはLTSを基準に検討します。

  • LTSを選ぶべきケース
    • 本番運用・企業システム: 安定性と長期的なセキュリティ更新を重視
    • フレームワークの推奨がLTS（例: Spring Bootの対応範囲）に寄っている場合
    • 複数年の保守を見据えて開発ラインを固定したい場合
  • 最新版（非LTS）を選ぶべきケース
    • 最新の言語機能・JVM改善をいち早く試したい検証・学習用途
    • 次期LTSへの準備として互換性やパフォーマンスを事前評価したい場合
  • 実務的な指針
    • 最低ラインはLTS（現行主流は17/21）。新規開発は21採用が無難
    • ビルドツール（Maven/Gradle）や主要ライブラリの対応状況を確認してから決定
    • 学習目的のjava インストールなら、LTSと最新版を並行評価して違いを体感するのも有効

最終的には、運用年数・サポートポリシー・利用フレームワークの互換性を軸に、LTS中心で選定し、必要に応じて最新版で先行検証する方針が現実的です。

WindowsでのJava（JDK）インストール手順

java+openjdk+installation

ここでは、Windows 10/11での「java インストール（JDK導入）」を、確認・ダウンロード・セットアップ・環境変数設定・動作確認・アンインストールの順に手早く進めるための手順として整理します。初めての方でも迷わないよう、GUI操作とコマンドの両方を示します。

既存のJDKが入っているか確認する

まずは既にJDKが入っているかを確認します。コマンドプロンプト（cmd）またはPowerShellを開き、次を実行してください。

java -version
javac -version
where java
where javac
  • バージョン情報が表示されれば、JDK（またはJRE）が導入済みです。
  • 「INFO: Could not find files」や「’java’ は内部コマンド…ではありません」と出る場合は未導入です。
  • 「where」コマンドで複数のパスが出る場合、複数JDKが共存しています（どれが優先かはPATHの並び順に依存）。
  • GUIでも「設定」→「アプリ」→「インストールされているアプリ」で「JDK」「Eclipse Temurin」「Microsoft Build of OpenJDK」「Amazon Corretto」などの有無を確認できます。

JDKをダウンロードする（配布元の選択）

Windows向けには複数の信頼できる配布元があります。プロジェクト要件に合うバージョン（例：x64/ARM64、必要なメジャー番号）を選び、通常はWindows用のインストーラ（MSI/EXE）を選択します。

Windowsのパッケージマネージャを使う方法（任意）:

# 例: Temurin 21 をインストール
winget install EclipseAdoptium.Temurin.21.JDK

# 例: Microsoft Build of OpenJDK 21 をインストール
winget install Microsoft.OpenJDK.21

注: wingetのIDは配布元やバージョンにより変わることがあります。検索は次で可能です。

winget search temurin
winget search openjdk

インストーラを実行してセットアップする

  1. ダウンロードしたMSI/EXEをダブルクリックして実行（必要に応じて管理者権限）。
  2. ライセンス条項を確認し、同意して進む。
  3. インストール先フォルダを確認（既定例: C:\Program Files\Eclipse Adoptium\jdk-21\ など）。特段の理由がなければ既定で問題ありません。
  4. セットアップオプションで「Add to PATH（PATHへ追加）」「Set JAVA_HOME（JAVA_HOMEを設定）」などがあれば有効化して進む。
  5. インストールを完了し、必要なら「Finish」後に新しいコマンドプロンプトを開く。

ZIP配布を選んだ場合は、任意のフォルダ（例: C:\Program Files\Java\jdk-21\）に展開し、後述の環境変数設定を手動で行ってください。

PATHとJAVA_HOMEを設定する

インストーラで自動設定されない場合は、手動で環境変数を設定します（システム全体に反映するには管理者権限が必要）。

  1. 「Windowsキー」→「このPC」を右クリック→「プロパティ」→「システムの詳細設定」→「環境変数」。
  2. 「システム環境変数」欄で「新規」をクリックし、変数名に「JAVA_HOME」、変数値にJDKのパス（例: C:\Program Files\Eclipse Adoptium\jdk-21）を入力して保存。
  3. 同じく「Path」を選択して「編集」→「新規」で「%JAVA_HOME%\bin」を追加。可能なら上位に移動し、古いJDKのbinより上に配置。
  4. すべて「OK」で閉じ、開き直したコマンドプロンプトで反映を確認。
echo %JAVA_HOME%
java -version
javac -version

PowerShellの場合の確認例:

$env:JAVA_HOME

インストール後にjava/javacのバージョンを確認する

正しく「java インストール」できたか、改めてバージョンを確認します。

java -version
javac -version
where java
where javac

表示されるパスが意図したJDKの場所であること、javaとjavacのバージョンが揃っていることを確認してください。

JDKをアンインストール（削除）する

不要になったJDKは以下の手順で削除します。

  1. 「設定」→「アプリ」→「インストールされているアプリ」（または「アプリと機能」）を開く。
  2. 該当するJDK（例: Eclipse Temurin JDK 21、Microsoft Build of OpenJDK、Amazon Corretto、Oracle JDKなど）を選び、「アンインストール」を実行。
  3. ZIP展開で導入した場合は、展開先フォルダ（例: C:\Program Files\Java\jdk-21\）を手動で削除。
  4. 環境変数「JAVA_HOME」やPath内の古いJDKエントリが残っていれば「環境変数」画面で削除。
  5. 新しいコマンドプロンプトを開き、次で残存を確認： 
    where java
where javac

以上でWindowsにおけるJDKの導入と削除の基本操作は完了です。必要に応じてこの手順を応用し、プロジェクトに適したバージョンのjava インストールを行ってください。

macOSでのJava（JDK）インストール手順

java+jdk+installation

macOSでのJava インストールは、配布元のPKGを使う方法とHomebrewを使う方法が主流です。ここでは既存JDKの確認から環境変数設定、バージョン切替、動作確認、アンインストールまでを一気通貫で解説します。macOSは標準でzshが既定シェルのため、設定例もzshを前提に記載します（bashの場合は~/.bash_profile等に読み替えてください）。

既存のJDKが入っているか確認する

先に既存のJava（JDK）が入っていないか確認します。複数バージョンが混在するとPATHやJAVA_HOMEの競合が起きやすいため、インストール前の現状把握は重要です。

# Javaランタイムのバージョン確認
java -version

# Javaコンパイラ（JDK同梱）の確認
javac -version

# macOSのJDK検出ユーティリティで一覧化（インストール済みのJDKを列挙）
/usr/libexec/java_home -V

# 現在のJAVA_HOMEがあれば表示
echo $JAVA_HOME

統合出力の例:

java version "21.0.3" 2024-04-16 LTS
javac 21.0.3
Matching Java Virtual Machines (3):
    21.0.3 (x86_64) "Temurin" - "OpenJDK 21.0.3" /Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home
    17.0.11 (x86_64) "Temurin" - "OpenJDK 17.0.11" /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
    1.8.0_402 (x86_64) "Zulu"   - "OpenJDK 1.8.0_402" /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home

JDKを入手してインストールする（PKG/Homebrew）

配布元のPKGを使う方法は、GUIで完結し手軽です。Homebrewは複数バージョンの管理や自動化に向きます。目的に応じて選びましょう。

  • PKG（GUI）でインストール
    • 代表的配布元: Eclipse Temurin (Adoptium)、Oracle JDK、Azul Zulu
    • 手順:
      1. 配布元サイトで目的のバージョン（例: 21 LTSや17 LTS）を選び、macOS用PKGをダウンロード
      2. .pkgをダブルクリックし、ウィザードに従ってインストール
      3. インストール先の多くは/Library/Java/JavaVirtualMachines/<ベンダ名-バージョン>.jdk
  • Homebrewでインストール（CLI）
    • Homebrewが未導入の場合は公式手順に従って導入
    • TemurinのLTSをcaskで導入（推奨・.jdkとして認識されやすい）
    # 最新LTS（例: 21）を導入
brew install --cask temurin

# バージョン指定（必要に応じて）
brew install --cask temurin17
brew install --cask temurin11
    • OpenJDK formulaを使う場合（.jdkバンドルでないためシンボリックリンクが必要）
    # 最新のOpenJDK（formula）
brew install openjdk

# macOSにJDKとして認識させるためのリンク（管理者権限）
sudo mkdir -p /Library/Java/JavaVirtualMachines
sudo ln -sfn "$(brew --prefix)/opt/openjdk/libexec/openjdk.jdk" \
  /Library/Java/JavaVirtualMachines/openjdk.jdk

シェル設定でPATH・JAVA_HOMEを反映する

PKGやcaskでインストールしたJDKは/usr/libexec/java_homeで検出でき、JAVA_HOMEへ簡単に設定できます。日常運用では特定バージョンを固定するか、ツールで切り替えるかを決めた上で設定します。

# 例: ~/.zshrc に追記（JDK 21 を既定に）
export JAVA_HOME=$(/usr/libexec/java_home -v 21)
export PATH="$JAVA_HOME/bin:$PATH"

# 設定を反映
source ~/.zshrc

# 確認
echo $JAVA_HOME
which java

Homebrewのopenjdk（formula）を使った場合にパスを通す例（brewのプレフィックスを汎用化）:

# ~/.zshrc
export PATH="$(brew --prefix)/opt/openjdk/bin:$PATH"

# 併用するならJAVA_HOMEも
export JAVA_HOME=$(/usr/libexec/java_home)

補足: zshが既定シェルです。bashをお使いの場合は~/.bash_profile等に同様の行を追記してください。

バージョン切替（/usr/libexec/java_home・jenv）の使い方

macOSの/usr/libexec/java_homeはシステム標準のJDKディスカバリ機構です。軽量な切替ならこれで十分です。複数プロジェクトでの柔軟な切替や細かな制御が必要ならjenvが便利です。

  • /usr/libexec/java_homeでの切替 
    # インストール済みJDKの一覧
/usr/libexec/java_home -V

# 一時的にJDK 17へ切替（現在のシェルだけ）
export JAVA_HOME=$(/usr/libexec/java_home -v 17)
export PATH="$JAVA_HOME/bin:$PATH"
java -version
  • jenvでの切替
    1. インストールと初期化
    brew install jenv

# シェル初期化（~/.zshrc に追記）
export PATH="$HOME/.jenv/bin:$PATH"
eval "$(jenv init -)"

# 反映
source ~/.zshrc
    1. JDKの登録と有効化
    # JDKの実体パスを追加（例）
jenv add /Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home
jenv add /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home

# 登録確認
jenv versions

# グローバル（全体）で21を使用
jenv global 21

# ディレクトリローカル（プロジェクト直下で）
jenv local 17

# 一時的（カレントシェルのみ）
jenv shell 21

    IDEやビルドツールとの整合が取れない場合は、eval “$(jenv init -)”が.zshrcに入っているか、which javaがjenvのshimを指しているかを確認してください。

インストール後の動作確認

Java インストール後はバージョンとコンパイル/実行の基本動作を確認します。

# バージョン確認
java -version
javac -version
echo $JAVA_HOME

# 簡単なHello World
cat > Hello.java <<'EOF'
public class Hello {
  public static void main(String[] args) {
    System.out.println("Hello, Java!");
  }
}
EOF

javac Hello.java
java Hello

期待される出力:

Hello, Java!

JDKをアンインストール（削除）する

不要になったJDKはクリーンに削除して、PATHやJAVA_HOMEの競合を防ぎます。導入方法ごとに手順が異なります。

  • PKG/caskで導入したJDK（.jdkバンドル）の削除
    • 共通: /Library/Java/JavaVirtualMachines/ 配下の対象JDKディレクトリを削除
    # 例: Temurin 17 の削除（管理者権限）
sudo rm -rf /Library/Java/JavaVirtualMachines/temurin-17.jdk
    • ユーザ領域に入っている場合（稀）: ~/Library/Java/JavaVirtualMachines/ 配下を削除
  • Homebrewで導入した場合 
    # cask（Temurinなど）
brew uninstall --cask temurin
brew uninstall --cask temurin17

# formula（openjdkなど）
brew uninstall openjdk

# 手動で作成したシンボリックリンクがあれば削除
sudo rm -f /Library/Java/JavaVirtualMachines/openjdk.jdk
  • 環境変数・設定の片付け 
    # ~/.zshrc からJAVA_HOMEやPATHの追記行、jenv初期化行を削除またはコメントアウト
# 反映
source ~/.zshrc

# jenvから該当JDKを除外（使わない場合）
jenv remove 21
jenv remove 17

最後に/usr/libexec/java_home -Vやjava -versionで不要なエントリが残っていないかを確認し、Java インストール環境が意図通りになっていることをチェックしてください。

LinuxでのJava（JDK）インストール手順

java+jdk+installation

LinuxでのJava インストールは、ディストリビューション標準のパッケージマネージャを使う方法と、配布アーカイブを手動で配置する方法の2通りが一般的です。ここではapt/dnf/yumを用いた導入から、手動配置、update-alternativesによるデフォルトJDKの切り替え、環境変数の設定、導入確認とアンインストールまで、実践手順をまとめます。

パッケージマネージャで導入する（apt/dnf/yum）

最も安全で簡単なJava インストール方法は、各ディストリビューションが提供するOpenJDKパッケージを使う手順です。ビルドや開発に必要なjavac等を含むJDKを選びます（Debian/Ubuntuはopenjdk-XX-jdk、RHEL系はjava-XX-openjdk-devel）。

  • Debian/Ubuntu系（apt）
sudo apt update
# 候補を検索
apt search openjdk
# 例: OpenJDK 17 をインストール（JDKパッケージ）
sudo apt install -y openjdk-17-jdk
# 必要に応じて 11 や 21 なども選べます
  • RHEL/Rocky/AlmaLinux/Fedora系（dnf）
# 候補を検索
dnf search openjdk
# 例: OpenJDK 17（JRE+開発ツール）をインストール
sudo dnf install -y java-17-openjdk java-17-openjdk-devel
  • CentOS 7など旧RHEL系（yum）
# 候補を検索
yum search openjdk
# 例: OpenJDK 11 をインストール
sudo yum install -y java-11-openjdk java-11-openjdk-devel

ポイント：RHEL系では「-devel」パッケージがJDK（javac等）に相当します。開発用途ではdevelを含めてインストールしてください。

アーカイブ配布から手動配置する

配布元のtar.gz/ tar.zst等のアーカイブから任意の場所に展開して使う方法です。複数バージョンを並行配置したい場合や、リポジトリにないビルドを使いたい場合に有効です。

  1. アーカイブを入手（各ベンダー配布ページから、OS/CPUアーキテクチャに合うJDKをダウンロード）
  2. 配置先ディレクトリを作成
sudo mkdir -p /opt/jdk
  1. アーカイブを展開（ファイル名はダウンロードした実物に置き換え）
sudo tar -xzf ~/Downloads/jdk-17_linux-x64_bin.tar.gz -C /opt/jdk
# 例: 展開先にできたディレクトリを確認
ls -1 /opt/jdk
# シンボリックリンクで「現在」を指すエイリアスを作ると管理が楽
sudo ln -sfn /opt/jdk/jdk-17* /opt/jdk/current
  1. 必要に応じて所有者を変更（単一ユーザーで使うならスキップ可）
sudo chown -R root:root /opt/jdk

手動配置したJDKは、後述のupdate-alternativesに登録するか、環境変数（JAVA_HOME/PATH）で明示的に参照するよう設定します。

update-alternativesでデフォルトJDKを切り替える

複数のJDKが入っている場合、システム全体で既定のjava/javacを切り替えるにはalternatives機構を使います。Debian/Ubuntuはupdate-alternatives、RHEL系はalternativesコマンド名が一般的です（実体は同等）。

  • インストール済みJDKの中から選択する
# Debian/Ubuntu
sudo update-alternatives --config java
sudo update-alternatives --config javac

# RHEL系（コマンド名がalternativesの場合）
sudo alternatives --config java
sudo alternatives --config javac
  • 手動配置したJDKを登録する（初回のみ）
# 例: /opt/jdk/current を登録し、優先度を2000に設定
sudo update-alternatives --install /usr/bin/java  java  /opt/jdk/current/bin/java  2000
sudo update-alternatives --install /usr/bin/javac javac /opt/jdk/current/bin/javac 2000
# その後、--configで選択
sudo update-alternatives --config java
sudo update-alternatives --config javac

注意：/usr/bin/javaを独自に上書きしないでください。必ずalternativesを介して切り替えると安全です。

環境変数（PATH・JAVA_HOME）を設定する

ビルドツールやIDEがJDKを正しく見つけるために、JAVA_HOMEとPATHの設定を行います。ユーザー毎（~/.bashrcや~/.zshrc）か、全体（/etc/profile.d）で設定可能です。

  • パッケージインストールの場合（自動検出）
# 現在選ばれているjavaからJAVA_HOMEを導出（bash）
echo 'export JAVA_HOME=$(dirname $(dirname $(readlink -f $(which java))))' >> ~/.bashrc
echo 'export PATH=$JAVA_HOME/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
  • 手動配置（固定パスを指定）
echo 'export JAVA_HOME=/opt/jdk/current' >> ~/.bashrc
echo 'export PATH=$JAVA_HOME/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

システム全体で反映したい場合は、同様の内容を/root権限で /etc/profile.d/jdk.sh に配置します。

導入確認とアンインストール手順

最後に、Java インストールが有効になっているか確認し、不要になった際の削除手順も押さえておきます。

  • 動作確認
which java
java -version
javac -version
echo $JAVA_HOME
  • インストール済みパッケージの確認
# Debian/Ubuntu
dpkg -l | grep -i openjdk

# RHEL系
rpm -qa | grep -i openjdk
  • アンインストール（パッケージ）
# Debian/Ubuntu（例: OpenJDK 17）
sudo apt remove --purge -y openjdk-17-jdk openjdk-17-jre
sudo apt autoremove -y

# RHEL/Fedora（例: OpenJDK 17）
sudo dnf remove -y java-17-openjdk java-17-openjdk-devel

# CentOS 7
sudo yum remove -y java-11-openjdk java-11-openjdk-devel
  • アンインストール（手動配置）
# alternativesの登録を外す（登録していた場合）
sudo update-alternatives --remove java  /opt/jdk/current/bin/java
sudo update-alternatives --remove javac /opt/jdk/current/bin/javac

# ディレクトリを削除
sudo rm -rf /opt/jdk/current /opt/jdk/jdk-17*
# 環境変数の設定を削除（~/.bashrc等から該当行を削除）

以上で、Linux上のJava（JDK）インストールから切り替え、環境変数設定、確認・削除までの実務に耐える手順を一通りカバーしました。用途に応じてapt/dnf/yumか手動配置を選び、update-alternativesと環境変数で確実に運用しましょう。

JDKの配布形態とライセンスの注意点

java+jdk+installation

業務や学習でJavaを使い始める前に、どのJDKディストリビューションを選ぶか、そしてそのライセンスや更新ポリシーを理解しておくことは、セキュリティやコスト、コンプライアンスの面で非常に重要です。ここでは、java インストール前に必ず押さえておきたい「Oracle JDK」と「OpenJDK」の違いと、企業利用時の更新・サポートの考え方を整理します。

Oracle JDKとOpenJDKの違い

現在のJavaエコシステムでは、機能面の差はJDK 11以降ほぼ解消され、どの配布でもJava SE仕様に準拠することが前提になっています。一方で「ライセンス」「更新提供の期間」「サポート体制」「再配布条件」などの非機能面で違いがあるため、用途に応じた選定が重要です。

観点 Oracle JDK OpenJDK（各ベンダー配布）
ソースと互換性 OpenJDKをベース。Java SE互換（TCK準拠）。 OpenJDKソース。Java SE互換（配布によりTCK合格を表明）。
ライセンス 近年のLTS（例：JDK 17/21など）は「Oracle No‑Fee Terms and Conditions（NFTC）」等。バージョンにより条件が異なるため都度確認が必要。 GPLv2 with Classpath Exception（CPE）。ディストリビューションごとに追加条項や利用規約が付く場合あり。
更新提供 四半期ごとのセキュリティ/バグ修正。NFTCの提供期間は「次のLTSのリリース後、一定期間まで」などバージョン依存。 ベンダーごと。Eclipse Temurin、Amazon Corretto、Microsoft Build of OpenJDK、Azul Zulu、Red Hat などがLTSの長期更新を提供。
サポート 商用サブスクリプションでエンタープライズサポート（契約が必要）。 無償利用のみ／商用サポートのいずれも選択可能（ベンダーにより有償サポートを提供）。
再配布 条項に制限あり。社内配布や再配布の可否はライセンスごとに確認必須。 GPL+CPEに基づくが、各ベンダーの配布条件も要確認（商用ロゴや追加コンポーネントの扱い等）。
入手形態 公式サイトからインストーラ/アーカイブ。MDM等での配布に対応。 各ベンダーがMSI/PKG/RPM/DEB/TARなどで提供。パッケージマネージャやコンテナイメージも充実。
  • 代表的なOpenJDK配布例（順不同）：Eclipse Temurin（Adoptium）、Amazon Corretto、Microsoft Build of OpenJDK、Azul Zulu、Red Hat build of OpenJDK、IBM Semeru など。
  • いずれも機能は同等を目指しますが、FIPS対応や古いCPU向け最適化、追加の検証プロセスなど、非機能面で差異があります。

重要：Oracle JDKは同じ「Oracle JDK」でもJDK 8、11、17、21などリリースごとにライセンス条件が異なる時期がありました。社内配布や商用利用の可否・期間はバージョン依存のため、必ず公式のライセンス文書を確認してください（参考：Oracle Java、OpenJDK）。

結論として、個人や学習用途でのjava インストールならどの配布でも開始できますが、業務や長期運用では「ライセンス条項」「更新の入手性」「サポート窓口」の3点を軸に配布元を選定するのが安全です。

企業利用時の更新ポリシーとサポート方針

企業でのjava インストールは、単に導入するだけでなく、継続的なセキュリティ更新とサポートをどう確保するかが要です。特にLTS版の扱い、四半期パッチの適用、障害時のエスカレーション経路をあらかじめ設計しましょう。

  • リリース/更新サイクル
    • Javaは半年ごとの機能リリース、定期的なLTSリリースが存在。四半期（1月・4月・7月・10月）のセキュリティ更新日に各ベンダーが修正を提供します。
    • LTS版は長期的な安定運用向け。非LTS（短期）の更新提供期間は短く、業務システムではLTS採用が一般的です.
  • ベンダー選定とサポート
    • 無償運用：Eclipse TemurinやAmazon Corretto等で四半期更新を継続取得。ただしトラブル時のSLAはありません。
    • 商用サポート：OracleのJava SE Subscription、Azul、Red Hat、IBM、Microsoft等が有償サポートを提供。SLAや長期のセキュリティバックポート、脆弱性対応の助言、互換性相談などが得られます（価格は契約に依存）。
    • プラットフォーム依存：RHELや特定クラウドでのサポートは、そのベンダー配布のOpenJDKと親和性が高い場合があります。
  • パッチ適用ポリシー
    • 四半期更新の即時評価・段階展開（検証→ステージング→本番）をプロセス化。
    • 依存関係（アプリ/ミドルウェア/ビルドツール）のリグレッションテストを自動化し、ロールバック手順を明文化。
  • コンプライアンスと配布
    • ライセンス遵守：社内再配布、コンテナイメージへの同梱、オフライン環境配布などは、配布元ごとの条項を確認。
    • 監査対応：導入バージョン、入手元、ライセンス種別、EOL日を資産管理台帳に記録し可視化。
  • 運用設計の実務ポイント
    • 標準JDKの統一（ディストリビューションとメジャー/LTSバージョンを全社で統一）。
    • サポート窓口の一本化（ベンダー契約または内部SREチーム）。
    • EOL/更改計画（次LTS発表時に移行計画を起案、バックポートの打切りに備える）。

まとめると、企業では「どのディストリビューションを、どのライセンスで、どれくらいの期間更新できるか」を起点に方針化し、四半期パッチとLTS更改を前提にした運用を整備するのがベストプラクティスです。導入前にライセンス文面とベンダーのサポートポリシーを必ず確認し、コンテナやVDIなど配布形態にも適用できるルールを整えてからjava インストールを実施しましょう。

複数バージョンの共存と切り替えガイド

java+jdk+installation

プロジェクトごとに必要なJDKが異なるケースは珍しくありません。Java 8/11/17/21といったLTSを並行運用し、即座に切り替えられる体制を整えると、検証やメンテナンスが大幅に効率化します。本章では、OS別に「安全に共存」「素早く切替」を実現する実践手順をまとめます。なお、いずれも事前に各JDKのjava インストール自体は完了している前提で、切替の運用ノウハウに絞って解説します。

Windowsでのバージョン切り替えのコツ

Windowsでは、複数のJDKフォルダを並置し、環境変数（特にJAVA_HOMEとPath）で「どれを使うか」を制御します。ポイントは「%JAVA_HOME%\\bin をPath先頭に固定し、JAVA_HOMEだけを切り替える」ことです。

  1. JDKの配置を整理する

    • 例: C:\Program Files\Java\jdk-8, jdk-11, jdk-17, jdk-21 のように分かりやすく設置。
    • 重要: Pathに特定JDKのbin（例: C:\Program Files\Java\jdk-17\bin）を直書きで複数並べない。優先度の衝突原因になります。

  2. 環境変数の基本設計

    • ユーザー（またはシステム）環境変数に JAVA_HOME を設定（例: C:\Program Files\Java\jdk-17）。
    • Pathの先頭付近に %JAVA_HOME%\bin を1行だけ追加（既存のJava/JREのbinは削除）。
    • 新しいコンソールを開いて反映（既存コンソールには反映されません）。

  3. PowerShellで高速切り替え（ユーザー環境変数を更新）

    # 管理者不要（ユーザー環境変数）。新しいターミナルで有効。
$Jdks = @{
  "8"  = "C:\Program Files\Java\jdk-8"
  "11" = "C:\Program Files\Java\jdk-11"
  "17" = "C:\Program Files\Java\jdk-17"
  "21" = "C:\Program Files\Java\jdk-21"
}
function Set-Java {
  param([Parameter(Mandatory)][ValidateSet("8","11","17","21")]$v)
  $home = $Jdks[$v]
  if (-not (Test-Path $home)) { throw "Not found: $home" }
  setx JAVA_HOME "$home" | Out-Null
  Write-Host "JAVA_HOME -> $home (新しいターミナルで有効)"
}
# 使い方:
# Set-Java 17
# Set-Java 21

    Pathは最初に1回だけ %JAVA_HOME%\bin を設定しておけば、以後は JAVA_HOME の切替のみで済みます。

  4. 即時の一時切替（現在のセッションのみ）

    # cmd.exe
set JAVA_HOME=C:\Program Files\Java\jdk-21
set PATH=%JAVA_HOME%\bin;%PATH%

# PowerShell
$env:JAVA_HOME = "C:\Program Files\Java\jdk-21"
$env:Path = "$env:JAVA_HOME\bin;$env:Path"

    この方法はターミナルを閉じると元に戻ります。検証時に便利です。

  5. 確認とトラブル回避

    where java
java -version
javac -version
    • 旧JREのbinがPath上位に残っていると予期せぬバージョンが使われます。必ず削除し、%JAVA_HOME%\binを最優先に。
    • 64bit/32bitの取り違えに注意（ツール類と同一アーキテクチャに揃える）。

macOSでのjenv活用手順

macOSではjenvを使うと、プロジェクト単位（ディレクトリ単位）・ユーザー単位・シェル単位でのJDK切替が簡単になります。java インストール後、各JDKをjenvに登録して使い分けます。

  1. jenvをインストール

    brew install jenv
# zsh想定（bashの方は .bashrc/.bash_profile を置換）
echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.zshrc
echo 'eval "$(jenv init -)"' >> ~/.zshrc
exec $SHELL -l

    これでjenvのshimsがPATH先頭に入り、jenv管理下のJavaが優先されます。

  2. JDKをjenvに登録

    # インストール済みJDKの一覧を把握
/usr/libexec/java_home -V

# 例: Temurin 17/21 を登録
jenv add /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
jenv add /Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home

# 登録状況の確認
jenv versions

  3. スコープ別の切替（global/local/shell）

    # ユーザー全体（デフォルト）を17に
jenv global 17

# プロジェクトディレクトリだけ11に
cd /path/to/project
jenv local 11   # .java-version が作成される

# 現在のターミナルだけ21に
jenv shell 21

    優先度は「shell > local > global」。状況に応じて使い分けます。

  4. JAVA_HOMEの自動連動（exportプラグイン）

    jenv enable-plugin export
exec $SHELL -l
echo $JAVA_HOME
java -version

    exportプラグインを有効にすると、切替に応じてJAVA_HOMEも自動で更新されます。

  5. トラブルシューティング

    • javaが切り替わらない: which java がjenvのshimsを指しているか確認。指していなければ eval "$(jenv init -)" の設定をシェルに追加し、再ログイン。
    • 古いJDKを削除した場合は、jenv remove で参照を整理。

Linuxでのupdate-alternatives活用

Debian/Ubuntu系ではupdate-alternatives、RHEL系ではalternativesを用いて、/usr/bin/java などのシステム既定を安全に切り替えます。手動展開したJDKも登録可能です。

  1. JDKを登録（Debian/Ubuntu系の例）

    # 例: /usr/lib/jvm に複数JDKがある前提
sudo update-alternatives --install /usr/bin/java  java  /usr/lib/jvm/jdk-17/bin/java  1710
sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/jdk-17/bin/javac 1710

sudo update-alternatives --install /usr/bin/java  java  /usr/lib/jvm/jdk-21/bin/java  2110
sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/jdk-21/bin/javac 2110
    • 最後の数字は優先度。大きいほど優先されます（–configで明示切替も可能）。
    • javaとjavacの両方を同じJDKで登録するのがコツです。

  2. デフォルトの切替

    sudo update-alternatives --config java
sudo update-alternatives --config javac

java -version
javac -version
which java

    javaとjavacが同じJDKを指しているかを必ず確認します。

  3. RHEL/CentOS/Fedora系の例

    # コマンド名が alternatives の場合
sudo alternatives --config java
sudo alternatives --config javac

    未登録のJDKを使いたい場合は、Debian系と同様に --install で登録してから --config で選択します。

  4. 手動展開したJDKの登録のコツ

    # 例: /opt/jdk/jdk-17 に展開した場合（Debian/Ubuntu系）
sudo update-alternatives --install /usr/bin/java  java  /opt/jdk/jdk-17/bin/java  1710
sudo update-alternatives --install /usr/bin/javac javac /opt/jdk/jdk-17/bin/javac 1710
    • ディレクトリの所有権と実行権限に注意（rootのみ読み取りにならないように）。
    • 切替後は新しいシェルで確認すると確実です。

以上の手順を押さえておけば、OSを問わず複数JDKの共存と迅速な切替が可能になります。java インストール後の運用負荷を最小化し、開発・検証・運用の全局面で再現性の高い環境を維持しましょう。

IDE・ビルドツールとの連携設定

java+jdk+installation

java インストールが完了したら、開発環境が正しいJDKを参照するように設定しましょう。ここでは主要IDEでのJDK指定方法と、Maven・Gradleが利用するJAVA_HOMEやツールチェーンの設定を整理します。誤ったJRE参照やバージョン不一致はビルド失敗や補完不全の原因になるため、最初に確実に整えるのが効率的です。

IntelliJ/Eclipse/VS CodeでJDKを指定する

IDEは「プロジェクトをどのJDKでコンパイル・実行するか」を個別に持ちます。JREではなくJDK（bin/javac を含む）を選んでください。

  • IntelliJ IDEAの場合（Community/Ultimate 共通）
    – メニュー「File > Project Structure…」を開き、左「Platform Settings > SDKs」で「+ > JDK」を選択し、JDKホーム（例: Windowsなら C:\Program Files\Java\jdk-17、macOSなら /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home など）を指定します。
    – 同画面の「Project Settings > Project」で「Project SDK」に追加したJDKを指定し、「Project language level」もJDKに合わせます。
    – モジュールごとに異なる場合は「Project Structure > Modules」でModule SDKを必要なJDKに切り替えます。
    – ビルドツール併用時のJDK指定（IDEランナー用）: 「Settings/Preferences > Build, Execution, Deployment」内で
    ・Gradle: 「Build Tools > Gradle > Gradle JVM」からJDKを選択
    ・Maven: 「Build Tools > Maven > JDK for importer / Runner」からJDKを選択
  • Eclipseの場合（Eclipse IDE for Java Developers 等）
    – 「Window > Preferences > Java > Installed JREs」で「Add… > Standard VM」を選択し、JDKホームを指定して追加。チェックを入れてデフォルトにします。
    – 「Preferences > Java > Installed JREs > Execution Environments」で、使用する「JavaSE-XX」を選び、先ほどのJDKにマップします。
    – プロジェクト単位: プロジェクトを右クリックし「Properties > Java Build Path > Libraries」で「JRE System Library」を追加/切替（Workspace default/Execution environment/Alternate JRE からJDKを選択）。
  • Visual Studio Codeの場合（Java Extension Packを利用）
    – コマンドパレットで「Java: Configure Java Runtime」を実行し、検出済みJDKの一覧から利用するものを関連付けます。
    – 複数JDKを明示する場合はユーザー設定（settings.json）に java.configuration.runtimes を定義します:

    {
  "java.configuration.runtimes": [
    { "name": "JavaSE-17", "path": "C:\\\\Program Files\\\\Java\\\\jdk-17" },
    { "name": "JavaSE-21", "path": "/Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home" }
  ]
}

    – 言語サーバー自体の起動JDKを固定したい場合は java.jdt.ls.java.home にJDKパスを設定します。
    – ビルドツールのインポート時に特定JDKを使う場合は、必要に応じて java.import.gradle.java.home / java.import.maven.java.home を設定します。
    – VS Codeの統合ターミナルからの実行はシステムのPATH/JAVA_HOMEに依存します。IDE内設定と併せて環境変数側も整えると一貫します。

確認のコツ: 各IDEで、ビルド出力や「About/Version」表示、あるいは内蔵ターミナルで java -version / javac -version を実行し、想定JDKが使われているかをチェックしてください。

Maven・GradleでJAVA_HOMEを設定する

Maven/Gradleは「ビルドを実行するJVM（ツールの起動JDK）」と「コンパイルに使うJDK（ターゲット）」の二層があります。手元のjava インストール後、環境変数やツールチェーンを正しく指定すると、CIやチーム全体でバージョンを統一できます。

  • 共通: 環境変数JAVA_HOMEの設定
    – 指すべき場所はJDKホーム（bin配下にjavacがあるディレクトリ）です。
    – 例（macOS/Linux・Bash/Zsh）:

    export JAVA_HOME=/path/to/jdk-17
export PATH="$JAVA_HOME/bin:$PATH"

    – 例（Windows・PowerShell セッション一時設定）:

    $env:JAVA_HOME="C:\Program Files\Java\jdk-17"
$env:Path="$env:JAVA_HOME\bin;$env:Path"

    – 反映確認: mvn -v / gradle -v または ./gradlew -v を実行し、表示される「Java home/JVM」が狙いのJDKか確認します。

  • MavenでのJDK固定（toolchains）
    – ユーザーごとに ~/.m2/toolchains.xml を作成し、利用可能なJDKを宣言します。プラグインはこのツールチェーンを解決してJDKを選びます。

    <toolchains>
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>17</version>
    </provides>
    <configuration>
      <jdkHome>/path/to/jdk-17</jdkHome>
    </configuration>
  </toolchain>
</toolchains>

    – POMではターゲットを明示（例: maven-compiler-plugin の <release>17</release>）。ツールチェーン対応プラグイン（compiler/surefire/javadoc等）は上記のtoolchains.xmlから適切なJDKを選びます。
    – 参考: 実行JVMは依然としてJAVA_HOMEに依存するため、Maven自体を起動するJDKとコンパイル用JDKを分けたい場合にツールチェーンが有効です。

  • GradleでのJDK固定（Java Toolchains）
    – プロジェクトの build.gradle（Kotlin DSLなら build.gradle.kts）にツールチェーンを宣言します（Gradle 6.7+）。

    plugins {
  id 'java'
}
java {
  toolchain {
    languageVersion = JavaLanguageVersion.of(17)
  }
}

    – これにより、ビルド（コンパイル/テスト/実行）に必要なJDK 17を自動的に解決・使用します（ローカルに見つからない場合は自動ダウンロードを試みる設定も可能）。
    – Gradle自体を起動するJDK（Gradle Daemon）は、通常JAVA_HOMEに依存します。プロジェクト/ユーザー単位で固定したい場合は、gradle.properties に以下を記述できます。

    org.gradle.java.home=/path/to/jdk-17

    – 代替として環境変数 GRADLE_JAVA_HOME を用いることもできます。
    – 確認: ./gradlew -version で「JVM」と「Java home」、ビルドログで「Provisioned toolchain」等の表示を確認します。

ポイントのまとめ: IDEのプロジェクトSDK、Maven/Gradleの起動JDK（JAVA_HOME）とコンパイルJDK（ツールチェーン/設定）は別物です。java インストール直後にこれらを整理しておくと、開発・ビルド・実行の一貫性が保たれ、将来のバージョンアップ時も安全に移行できます。

よくあるトラブルと対処法

java+jdk+installation

「java インストール」を終えた直後や既存環境をアップデートした際に起こりがちな不具合と、原因切り分けから最短で復旧するための具体策をまとめます。OSごとにコマンドが異なるため、Windows・macOS・Linuxの順にチェックしながら進めてください。

java/javacが見つからない場合の対応

コマンドが見つからない場合は、JDK未導入・パス未設定・シェル設定未反映のいずれかが典型です。まずは症状と現状を可視化し、次にPATH/JAVA_HOMEの整合性を直します。

  • よくあるエラーメッセージ 
    # Windows
'java' は内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチ ファイルとして認識されていません。

# macOS/Linux
zsh: command not found: java
bash: javac: command not found
  • 現状確認（優先パスと実体の場所） 
    # Windows（PowerShell または CMD）
where java
where javac
echo %JAVA_HOME%
echo %PATH%

# macOS/Linux
which java
which javac
echo $JAVA_HOME
echo $PATH

# macOS（インストール済みJDKの一覧）
/usr/libexec/java_home -V
  • 原因と対処の要点
    • JDKが未導入 → まずJDKを導入してください（JREではjavacが含まれません）。
    • PATHにJDKのbinがない → PATHへJDKのbinを先頭付近に追加。
    • JAVA_HOME未設定/誤設定 → JDKルートを指すよう修正（binではなくJDKディレクトリ）。
    • シェル設定未反映 → 新しいターミナルを開き直すか設定を再読み込み。

代表的な設定例（導入済みを前提）

# Windows（管理者として実行推奨、再起動または再ログインで反映）
setx JAVA_HOME "C:\Program Files\Java\jdk-17"
setx PATH "%JAVA_HOME%\bin;%PATH%"

# macOS（zshが既定なら ~/.zshrc へ）
echo 'export JAVA_HOME=$(/usr/libexec/java_home -v 17)' >> ~/.zshrc
echo 'export PATH="$JAVA_HOME/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

# Linux（例: Debian/UbuntuのOpenJDK 17）
echo 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64' | sudo tee -a /etc/environment
echo 'export PATH="$JAVA_HOME/bin:$PATH"' | sudo tee -a /etc/profile.d/java.sh
source /etc/profile.d/java.sh

補足: macOSで「No Java runtime present, requesting install」が出る場合は、古いApple製Javaの案内です。最新JDKを導入し、/usr/libexec/java_home による設定に切り替えてください。

旧バージョンが優先されるときの解決策

複数のJDK/JREが同居していると、意図しない古いバージョンが先に見つかることがあります。優先順位は「どのパスが先にPATHへ来るか」「システムの代替設定（alternativesなど）」で決まります。

  • 状況の見える化 
    # バージョン確認
java -version
javac -version

# どの実行ファイルが使われているか
# Windows
where java
where javac
# macOS/Linux
which java
which javac
readlink -f $(which java) 2>/dev/null
readlink -f $(which javac) 2>/dev/null
  • Windowsの対処
    • 環境変数で統一管理: システム環境変数JAVA_HOMEを目的のJDKに設定し、PATHの先頭近くに「%JAVA_HOME%\bin」を配置。
    • 古いJDK/JREのbinパスがPATH上位にある場合は削除または下位へ移動。
    • 不要な旧バージョンはアンインストールを検討。
  • macOSの対処
    • /usr/libexec/java_home -V で全JDKを把握し、使いたいバージョンを明示: 
      export JAVA_HOME=$(/usr/libexec/java_home -v 17)
export PATH="$JAVA_HOME/bin:$PATH"
    • シェル起動時に毎回反映されるよう、.zshrc などに記載。
    • 旧JREの残骸（/Library/Java/JavaVirtualMachines 以外のディレクトリや独自パス）に注意し、PATHから除外。
  • Linuxの対処
    • OSの代替システムで切替: 
      sudo update-alternatives --config java
sudo update-alternatives --config javac
    • 手動PATH運用の場合は、目的のJDKのbinをPATH先頭に配置し、JAVA_HOMEも合わせる。
    • パッケージと手動配置が混在していると衝突しやすいので、どちらかに統一。

ポイント: PATHは左から順に評価されます。意図したJDKのbinが最も早く見つかるよう順序を整え、JAVA_HOMEと整合させると安定します。

IDEがJDKを認識しないときのチェックポイント

IDEがプロジェクトSDKとしてJDKを掴めない場合、多くはパスの指し先やアーキテクチャ不一致が原因です。以下の観点で確認します。

  • JDK/JREの取り違え
    • コンパイルにはJDKが必要です。JREのみを指定していないか確認（bin/java はあっても bin/javac がない場合はJRE）。
    • IDEの「JDKホーム」はJDKのルート（…/jdk-17 など）を指定し、bin配下を直接指定しない。
  • アーキテクチャ/OSとの整合
    • Apple Silicone(Mシリーズ)ならaarch64/arm64のJDK、Intelならx64を使用。混在すると起動や認識に失敗。
    • Windowsのx86/x64取り違いにも注意。
  • IDEの設定レイヤー
    • IDE全体のJDK設定（例: Project SDK/Installed JDKs）と、プロジェクトごとのSDK/言語レベル設定が一致しているか。
    • Gradle/Mavenが別JDKを使っていないか（Gradle JVM、MavenのJAVA_HOME）。ビルドツール側のJDKが古いと同期に失敗します。
  • パスと権限
    • JDKパスに空白・マルチバイトが含まれる場合、IDEやプラグインが誤解釈することがあります。短いASCIIパスで再設定を試す。
    • 企業環境ではウイルス対策/実行制御でJDKの実行がブロックされることがあるため、セキュリティポリシーと例外設定を確認。
  • 動作検証のミニテスト 
    javac -version
java -version
# IDE内のターミナル/ビルド出力でも同じバージョンを指しているかを確認

上記を確認しても解決しない場合は、IDEのキャッシュ再構築（インデックス再作成）や、プロジェクト設定の再読み込みを試してください。JDKの再指定後はIDEを再起動すると認識が安定します。

サーバー・コンテナ環境でのインストールのポイント

java+jdk+docker

サーバーやコンテナでのjava インストールは、開発端末とは発想が異なります。サイズ削減、再現性、セキュリティパッチの適用容易性、起動の安定性などを満たすため、ビルド用と実行用を分離し、最小構成で運用するのが基本です。以下では、そのための着眼点と実践的な導入方法を解説します。

JDKにJREが含まれる点と最小イメージ化の考え方

近年のJDK配布（特に11以降）では、実行に必要なランタイム（従来のJRE相当）がJDKに同梱されており、別個のJRE配布がないケースが一般的です。サーバーやコンテナでは「ビルドはJDK、実行は最小ランタイム」という分離が定石で、次の戦略が有効です。

  • ビルドと実行の分離: マルチステージビルドで、コンパイルやテストはJDKイメージ上で行い、実行ステージはJRE相当またはカスタムランタイムに切り替えます。これにより、攻撃対象を減らし、転送容量や起動時間を抑えられます。
  • jlinkでカスタムランタイムを作成: JDKに含まれるjlinkを使い、必要なモジュールだけを束ねたランタイムを生成します。典型的にはjava.base、java.logging、jdk.crypto.ec（TLS楕円曲線）などを選定し、デバッグシンボルやマニュアルを削除してサイズを削減します。依存モジュールは事前にjdepsで把握できます。
# 依存モジュールの洗い出し（例）
$ jdeps --print-module-deps app.jar
# ランタイムの作成（例）
$ jlink \
  --add-modules java.base,java.logging,jdk.crypto.ec \
  --strip-debug --no-man-pages --no-header-files --compress=2 \
  --output /opt/jre-min
  • ベースOSの選定: Debian/Ubuntu系のslimやRed Hat系の最小イメージ、あるいはdistrolessなどを活用します。Alpineのようなmusl libcベースは一部ネイティブ依存で注意が必要です（glibc前提のバイナリやライブラリが動かない場合があります）。
  • 「動く最小限」を満たす付帯パッケージ: サーバー実行でも、TLSとタイムゾーンはほぼ必須です。ca-certificatesとtzdata（タイムゾーン）、必要に応じてロケール（glibc-locale関連）、フォント（PDF生成等がある場合）を最小限導入します。GUIは不要ならheadlessで十分です。
  • コンテナ制限への最適化: 近年のJDKはcgroupのCPU/メモリ制限を自動認識します。-XX:MaxRAMPercentageや-XX:InitialRAMPercentageなどの割合指定を使うと、メモリサイズが変化しても安定しやすくなります。
  • セキュリティと再現性: 実行ステージは非rootユーザーで動かし、イメージはSBOM/署名、チェックサム検証を取り入れてサプライチェーンリスクを低減します。

DockerベースイメージでのJDK導入方法

コンテナでのjava インストールは、用途に応じて「公式JDK/JREイメージ利用」「jlinkで自作ランタイム」「アーカイブ配置」の3パターンが定番です。以下に実践的なDockerfile例を示します。

  • 公式のJDK/JREイメージを使う（マルチステージの基本形）
# ビルド用ステージ（JDK）
FROM eclipse-temurin:21-jdk AS build
WORKDIR /app
COPY . .
# 例: Gradleでビルド（キャッシュ活用のため、実プロジェクトではラッパ/依存定義を先にCOPY）
RUN ./gradlew --no-daemon clean build -x test

# 実行用ステージ（JRE相当）
FROM eclipse-temurin:21-jre AS run
ENV JAVA_OPTS="-XX:MaxRAMPercentage=75 -XX:InitialRAMPercentage=25 -XX:+ExitOnOutOfMemoryError"
# タイムゾーンと証明書（必要に応じて）
RUN apt-get update \
 && apt-get install -y --no-install-recommends tzdata ca-certificates \
 && rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY --from=build /app/build/libs/app.jar /app/app.jar
# 非rootで実行
RUN useradd -r -u 10001 appuser
USER 10001
EXPOSE 8080
ENTRYPOINT ["sh","-c","java $JAVA_OPTS -jar /app/app.jar"]
  • jlinkで最小ランタイムを組み込む（さらに軽量化）
# 1) ランタイム生成ステージ
FROM eclipse-temurin:21-jdk AS jre-builder
RUN $JAVA_HOME/bin/jlink \
    --add-modules java.base,java.logging,jdk.crypto.ec \
    --strip-debug --no-man-pages --no-header-files --compress=2 \
    --output /opt/jre-min

# 2) アプリのビルド
FROM eclipse-temurin:21-jdk AS build
WORKDIR /app
COPY . .
RUN ./mvnw -B -DskipTests package

# 3) 実行ステージ（最小ベース + 自作JRE）
FROM gcr.io/distroless/base-debian12 AS run
ENV PATH="/opt/jre-min/bin:${PATH}" \
    JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75 -XX:InitialRAMPercentage=25 -Dfile.encoding=UTF-8"
COPY --from=jre-builder /opt/jre-min /opt/jre-min
COPY --from=build /app/target/app.jar /app/app.jar
USER nonroot
WORKDIR /app
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app/app.jar"]
  • アーカイブ（tar.gz）からの手動配置（ネットワーク制限環境や特定ディストリ向け）
FROM debian:12-slim
# 署名/Checksum検証は実運用で必須（ここでは概念を示す）
ARG JDK_URL="https://example.invalid/vendor-openjdk21-linux-x64.tar.gz"
RUN apt-get update \
 && apt-get install -y --no-install-recommends curl ca-certificates tzdata \
 && rm -rf /var/lib/apt/lists/*
RUN mkdir -p /opt/java \
 && curl -fsSL "${JDK_URL}" | tar -xz -C /opt/java --strip-components=1
ENV JAVA_HOME=/opt/java
ENV PATH="$JAVA_HOME/bin:${PATH}"
# 以降はアプリ配置・非root化・ENTRYPOINT設定は前例と同様
  • 補足のベストプラクティス
  • イメージのタグはダイジェスト固定（@sha256:…）で再現性を確保。
  • 必要最小限のパッケージのみ追加し、ビルド後はキャッシュを削除してレイヤを小さく保つ。
  • multi-arch（linux/amd64, linux/arm64）対応が必要ならbuildxでビルド。
  • 起動パラメータはENV（JAVA_TOOL_OPTIONS/JAVA_OPTS）で外出しし、リリースごとにDockerfileを変えない。

これらを踏まえてjava インストールを最小・安全・再現性高く行うと、サーバーやコンテナ運用のコストを大幅に抑えられます。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

前の記事

javascript とは？基礎から最新動向まで完全ガイド

次の記事

java マイクラ完全ガイド: 違い・価格・導入・サーバー