Javaの環境変数を設定する10ステップ

はじめに

Javaの環境変数は、JDKの場所をOSや開発ツールへ伝えるための設定です。PATHにbinディレクトリを通し、必要に応じてJAVA_HOMEを用意すると、ターミナルやIDEからjavaとjavacを呼び出しやすくなります。

そのため、Javaのセットアップで最初に確認したいのは、JDKがどこに入り、どの環境変数から参照されているかという点になります。初心者ガイドとして読む場合も、コーディング前の土台を整える作業だと考えると理解しやすいでしょう。

Javaの設定はOSごとに画面やコマンドが異なりますが、考え方は共通しているのが基本です。プログラミング作業で迷わないよう、サンプルコードと確認コマンドを組み合わせながら、環境変数の詳細解説と応用例まで整理するのが基本です。

Javaと環境変数の基本

結論から言うと、Javaの環境変数で最初に確認する対象はPATHとJAVA_HOMEです。PATHはコマンド検索先を増やし、JAVA_HOMEはJDKのルートディレクトリをツールへ伝えます。

java -version

結果: 期待される出力は、インストール済みJavaのバージョン情報です。command not foundや認識されていませんが出る場合は、PATHの設定を確認します。

これが通れば、OSはJavaの実行ファイルを見つけられているのが目安です。ただし、ビルドツールやIDEはJAVA_HOMEを見ることがあるため、javaだけでなくjavacも確認するのが現実的です。

javac -version

結果: 期待される出力は、Javaコンパイラのバージョンです。JREだけではjavacが入らないため、開発用途ではJDKのセットアップが必要になるのが目安です。

Javaの位置づけ

Javaは、ソースコードを.javaファイルに書き、javacで.classへコンパイルし、JVM上で実行するプログラミング言語です。その流れではjavaコマンド、javacコマンド、ライブラリ検索先がそれぞれ関わります。

一般に、JDKをインストールしただけでは、すべてのシェルが自動でJavaを見つけられるとは限りません。そのため、PATHへbinを追加し、JAVA_HOMEへJDKの親ディレクトリを登録する設定が使われますし、ここがポイントです。

公式ドキュメントで仕様を確認する場合は、Oracle Java APIのSystem.getenvと、Oracleのjavaコマンド仕様が一次情報として役立ちます。これらはJavaコードから環境変数を読む場面や、起動オプションを確認する場面で参照できます。

環境変数の意味と役割

環境変数は、OSやプロセスに渡される名前付きの値です。JavaではSystem.getenv()で読み取れますが、通常のJavaコードからOS全体の環境変数を永続的に書き換える用途には向きません。

その違いを押さえると、初心者がつまずきやすい原因を分けられますが、これは押さえたい点です。System.setProperty()はJavaのシステムプロパティを扱い、System.getenv()はOSから渡された環境変数を読むため、両者は同じ設定ではありません。

💡 Tips: Javaの起動確認はjava -version、コンパイル確認はjavac -version、JDK位置の確認はJAVA_HOMEという形で役割を分けると、設定ミスを追いやすくなります。

Javaの環境変数の詳細な設定法

Javaの環境変数の設定は、JDKのインストール場所を確認し、PATHとJAVA_HOMEへ正しい値を入れ、別のシェルで反映を確認する流れになります。サンプルコードはOSごとに分かれますが、狙いは同じです。

サンプルコード1：Javaコードから環境を確認する

このサンプルコードは、JavaからJAVA_HOMEとjava.homeを読み比べます。環境変数とシステムプロパティの違いを確認できるため、初心者ガイドの最初の確認として扱いやすい例です。

public class EnvCheck {
    public static void main(String[] args) {
        System.out.println("JAVA_HOME=" + System.getenv("JAVA_HOME"));
        System.out.println("java.home=" + System.getProperty("java.home"));
    }
}

結果: 期待される出力は、JAVA_HOMEの値とJava実行環境が使うjava.homeの値です。両者が完全一致しない環境もあるため、用途を分けて確認します。

ただし、このコードは環境変数を変更するためのものではありません。Javaアプリケーション内で値を読むサンプルコードであり、OS側の設定はシェルや管理画面から行うのが基本になります。

サンプルコード2：WindowsでPATHを追加する

Windowsでは、setxでユーザー環境変数を永続化できるのがポイントです。ただし、既存のPATHを長くしすぎると管理しづらくなるため、現在の値を控えてから設定するほうが安全です。

setx PATH "%PATH%;C:Program FilesJavajdk-21in"

結果: 期待される表示は、値が保存されたことを示すWindowsのメッセージです。反映は新しく開いたコマンドプロンプトやPowerShellで確認します。

このとき、Javaのインストール先がC:Program FilesJavajdk-21ではない場合は、実際のJDKパスへ置き換えます。binまで含めるのはPATHで、JAVA_HOMEには通常binを含めません。

サンプルコード3：macOSとLinuxでPATHを追加する

macOSやLinuxでは、シェルの設定ファイルにexportを書いて永続化するのが一般的です。使用シェルがbashなら.bashrc、zshなら.zshrcが候補になるのがポイントです。

export PATH=$PATH:/usr/lib/jvm/jdk-21/bin

結果: 期待される状態は、新しいシェルでjavaコマンドが検索対象に入ることです。永続化する場合は、利用中シェルの設定ファイルへ追記します。

その設定を即時反映したい場合は、対象ファイルをsourceで読み込みますし、これが一つの目安です。一方、ログインシェルや非ログインシェルの違いにより、読み込まれるファイルが変わる点には注意が必要です。

source ~/.zshrc

結果: 期待される状態は、現在のシェルに追記内容が読み込まれることです。エラーが出た場合は、ファイル名や記述したパスを確認します。

サンプルコード4：LinuxでJavaの場所を探す

Javaの場所が分からない場合は、コマンドから候補を調べますし、ここがポイントです。ディストリビューションやインストール方法によってJDKの配置先が変わるため、推測で書くより確認してから設定するほうが確実です。

whereis java

結果: 期待される出力は、javaに関連するファイルやディレクトリの候補です。シンボリックリンクをたどる必要がある場合は、readlinkも併用するのが現実的です。

readlink -f $(which java)

結果: 期待される出力は、現在呼び出されているjava実行ファイルの実体パスです。そこからbinの親をたどると、JDKの位置を推定できます。

サンプルコード5：JAVA_HOMEを設定する

JAVA_HOMEは、JDKのルートディレクトリを指します。binまで含めると、MavenやGradleなどのツールが期待する形とずれることがあるため、値の末尾を確認すると整理できるのが一般的です。

export JAVA_HOME=/usr/lib/jvm/jdk-21

結果: 期待される状態は、現在のシェルと子プロセスからJAVA_HOMEを参照できることです。永続化するには.bashrcや.zshrcへ同じ行を追記します。

echo $JAVA_HOME

結果: 期待される出力は、設定したJDKのルートパスです。空欄ならシェルへ反映されていないか、設定ファイルが読み込まれていません。

Windowsの場合は、環境変数の画面からJAVA_HOMEを追加する方法もあります。コマンドで扱う場合はsetxが使えますが、反映は新規セッションからになる点を押さえますが、覚えておくと役立つでしょう。

setx JAVA_HOME "C:Program FilesJavajdk-21"

結果: 期待される表示は、JAVA_HOMEが保存されたことを示すメッセージです。既に開いているシェルには反映されないため、新しい画面で確認するのが現実的です。

サンプルコード6：macOSでJAVA_HOMEを求める

macOSには、インストール済みJavaのホームを返す/usr/libexec/java_homeがあります。複数バージョンがある場合にも、条件付きでパスを取得できると理解できます。

/usr/libexec/java_home

結果: 期待される出力は、macOSが認識しているJDKのホームディレクトリです。出力がない場合は、JDKのインストール状態を確認すると整理できます。

export JAVA_HOME=$(/usr/libexec/java_home)

結果: 期待される状態は、JAVA_HOMEにmacOSが返したJDKパスが入ることです。.zshrcへ記載すれば、以後のセットアップが楽になります。

サンプルコード7：CLASSPATHを設定する

CLASSPATHは、Javaがクラスやライブラリを探す場所を表すると覚えるとよいでしょう。ただし、近年のコーディングではビルドツールや-cpで明示する形が多く、グローバルなCLASSPATHは必要な場合に限定するのが扱いやすいです。

set CLASSPATH=C:Javalibs;C:Javaclasses

結果: 期待される状態は、現在のWindowsセッションでCLASSPATHが参照されることです。永続化したい場合は環境変数画面やsetxを検討します。

java -cp C:Javaclasses YourClassName

結果: 期待される表示は、YourClassNameのmainメソッドが出力する内容です。クラスが見つからない場合は、パッケージ名とディレクトリ構造を確認します。

同様に、Unix系では区切り文字がセミコロンではなくコロンになると考えられますが、これは押さえたい点です。OSで区切り文字が変わる点は、環境変数の詳細解説で見落とされやすい部分です。

java -cp /opt/app/classes:/opt/app/libs/* com.example.Main

結果: 期待される表示は、com.example.Mainが出力する内容です。ワイルドカードを使う場合は、シェル展開とJavaランチャー側の扱いを区別します。

サンプルコード8：複数バージョンを切り替える

複数のJavaを使う場合は、プロジェクトごとにJAVA_HOMEとPATHを切り替えます。Windowsではバッチファイル、macOSやLinuxではシェル関数や専用ツールを使う構成が一般的だと言えますし、ここを基本と考えるとよいでしょう。

@echo off
set "JAVA_HOME=C:Program FilesJavajdk-21"
set "PATH=%JAVA_HOME%in;%PATH%"
echo Java version switched to: 21

結果: 期待される表示は、Java version switched to: 21です。この変更はバッチを実行したセッションで有効になり、システム全体の設定を直接書き換えるものではありません。

一方、macOSやLinuxでは、シェル関数で同じ発想を使えます。チーム開発では、READMEに切替方法を残しておくと、セットアップの差を減らせます。

use_java_21() {
  export JAVA_HOME=/usr/lib/jvm/jdk-21
  export PATH=$JAVA_HOME/bin:$PATH
}

結果: 期待される状態は、use_java_21を呼び出した後にJava 21系のコマンドが優先されることです。既存のPATHに古いJDKが残る場合は順序を確認すると言えるでしょう。

サンプルコード9：環境変数を確認する

確認は、設定と同じくらい大切です。Javaのコーディングでエラーが出たとき、原因がソースコードではなく環境変数にあるケースもあるため、最初に値を見る習慣を作ります。

echo %JAVA_HOME%

結果: 期待される出力は、Windowsに登録されたJAVA_HOMEの値です。%JAVA_HOME%のまま表示される場合は、変数が見つかっていない可能性があります。

java -version

結果: 期待される出力は、使用中のJavaランタイムのバージョン情報です。想定と違うバージョンなら、PATHの先頭側に別JDKが入っていないか確認するのが基本です。

サンプルコード10：エラー時にJavaコードで確認する

Javaプログラム内でも、必要な環境変数が存在するかを検査できると理解できます。外部APIのURLやプロジェクト固有のパスを環境変数で渡す場合、起動時に明確なエラーを出すと原因を追いやすくなります。

public class EnvironmentVariableErrorSolution {
    public static void main(String[] args) {
        String javaHome = System.getenv("JAVA_HOME");
        if (javaHome == null || javaHome.isBlank()) {
            throw new IllegalStateException("JAVA_HOME環境変数が設定されていません。");
        }
        System.out.println("JAVA_HOMEの設定は正常です: " + javaHome);
    }
}

結果: 期待される出力は、JAVA_HOMEがある場合は正常メッセージ、ない場合は例外メッセージです。動作未確認の環境では、出力文言はJDKや実行方法で変わる可能性があります。

Exception in thread "main" java.lang.IllegalStateException: JAVA_HOME環境変数が設定されていません。

結果: 期待される出力例は、JAVA_HOMEが未設定であることを示す例外です。実際の行番号やスタックトレースはファイル名とコード位置によって変わります。

サンプルコード11：JAVA_OPTSを追加する

JAVA_OPTSは標準仕様そのものではなく、アプリケーション起動スクリプトが読む慣習的な変数として使われますし、ここがポイントです。そのため、設定しただけで全Javaプロセスへ自動適用されるとは限りません。

export JAVA_OPTS='-Xmx1024m'

結果: 期待される状態は、現在のシェルでJAVA_OPTSに-Xmx1024mが入ることです。起動スクリプト側がこの値をjavaコマンドへ渡す設計である必要があります。

echo $JAVA_OPTS

結果: 期待される出力は、-Xmx1024mです。空欄なら設定が現在のシェルへ反映されていません。

export JAVA_OPTS='-Xmx1024m -Xms512m'

結果: 期待される状態は、最大ヒープサイズと初期ヒープサイズの両方を起動オプションとして扱えることです。値が大きすぎると起動に失敗する場合があります。

public class CheckJavaOpts {
    public static void main(String[] args) {
        long maxMemory = Runtime.getRuntime().maxMemory();
        long totalMemory = Runtime.getRuntime().totalMemory();
        System.out.println("最大ヒープサイズ: " + maxMemory / (1024 * 1024) + "MB");
        System.out.println("初期ヒープサイズ: " + totalMemory / (1024 * 1024) + "MB");
    }
}

結果: 期待される出力は、JVMが認識している最大ヒープサイズと初期ヒープサイズです。OSやJVMの実装により、指定値と表示値が完全には一致しない場合があります。

java $JAVA_OPTS CheckJavaOpts

結果: 期待される表示は、CheckJavaOptsが出力するメモリ情報です。JAVA_OPTSを明示的に渡しているため、変数の値が起動時オプションとして使われます。

サンプルコード12：Java更新後の同期

Javaを更新した後は、古いJDKのパスがPATHやJAVA_HOMEに残る場合があるのが目安です。バージョンだけ新しくしても、シェルが古い実行ファイルを先に見つけると、期待した環境になりません。

public class UpdateJavaPath {
    public static void main(String[] args) {
        String javaHome = System.getProperty("java.home");
        System.out.println("現在のjava.home: " + javaHome);
    }
}

結果: 期待される出力は、現在のJava実行環境が参照しているjava.homeです。この値はOSのJAVA_HOMEを書き換えるものではなく、起動中JVMの参照先を確認するための情報です。

この確認と合わせて、where javaやwhich javaで実行ファイルの位置も見ます。両方を見ることで、環境変数と実行コマンドのずれを見つけやすくなります。

where java

結果: 期待される出力は、Windowsで見つかったjava.exeの候補一覧です。上に出たパスほど優先されますが、これは押さえたい点です。

Javaの環境変数の応用例

Javaの環境変数は、JDKの場所を示すだけでなく、プロジェクトごとの設定や外部ツール連携にも使えると覚えるとよいでしょう。応用例では、ソースコードに秘密情報や環境差分を埋め込まず、起動環境から値を渡す考え方が中心になります。

具体的には、APIエンドポイント、データ保存先、外部コマンドの場所などを環境変数へ分けると、同じJavaコードを開発環境と本番環境で使い回しやすくなるのがポイントです。これはプログラミングの保守性にも関係します。

サンプルコード13：特定プロジェクトだけで使う環境変数

プロジェクト専用の環境変数は、名前にアプリケーション名を含めると衝突を避けやすくなると考えられます。たとえばPROJECT_PATHやAPI_ENDPOINTは、用途が読み取りやすい名前です。

public class ProjectSpecificSettings {
    public static void main(String[] args) {
        String projectPath = System.getenv("PROJECT_PATH");
        String apiEndpoint = System.getenv("API_ENDPOINT");
        System.out.println("プロジェクトのパス: " + projectPath);
        System.out.println("APIエンドポイント: " + apiEndpoint);
    }
}

結果: 期待される出力は、PROJECT_PATHとAPI_ENDPOINTの値です。未設定の場合はnullが表示されるため、実運用では未設定チェックを追加します。

export PROJECT_PATH='/path/to/your/project'
export API_ENDPOINT='https://api.example.com'

結果: 期待される状態は、現在のシェルから起動したJavaプロセスが2つの値を読めることです。URLは例示なので、実際の接続先へ置き換えます。

プロジェクトのパス: /path/to/your/project
APIエンドポイント: https://api.example.com

結果: 期待される出力例は、設定した値がそのまま表示される形です。機密情報を出力する場合はログに残るため、表示内容を制限するのが一般的です。

同様の考え方は、Java List型完全ガイドのようなデータ処理でも役立ちますし、これが一つの目安です。入力ファイルの場所を環境変数に分ければ、コード本体を変えずに実行対象を切り替えられます。

サンプルコード14：JavaとPythonを連携する

他言語との連携では、Javaから外部プロセスを起動する場面があるのが現実的です。現在はRuntime.getRuntime().exec()より、引数を分けて扱いやすいProcessBuilderを使うほうが安全に整理できます。

import java.io.BufferedReader;
import java.io.InputStreamReader;

public class JavaPythonIntegration {
    public static void main(String[] args) throws Exception {
        Process process = new ProcessBuilder("python", "script.py").start();
        try (BufferedReader reader = new BufferedReader(
                new InputStreamReader(process.getInputStream()))) {
            String line;
            while ((line = reader.readLine()) != null) {
                System.out.println(line);
            }
        }
        int exitCode = process.waitFor();
        System.out.println("終了コード: " + exitCode);
    }
}

結果: 期待される出力は、Pythonスクリプトの標準出力と終了コードです。Pythonの実行ファイル名やパスは環境によって異なるため、必要に応じて絶対パスを使います。

print("Pythonスクリプトが正常に処理されました")

結果: 期待される出力は、Python側のprintで書いた文字列です。Java側はその標準出力を読み取り、コンソールへ流します。

その連携では、PythonのパスをPYTHON_HOMEのような独自変数で管理することもあると整理できると言えるでしょう。ただし、環境変数を増やしすぎるとコーディング時の前提が見えにくくなるため、READMEや設定一覧に残します。

アノテーションを使って設定クラスを整理する設計なら、Javaアノテーションの解説記事も関連します。環境変数から読んだ値を設定オブジェクトへ集約すると、テストしやすい構造になると理解できるのが基本です。

サンプルコード15：環境変数をMapとして読む

Javaでは、すべての環境変数をMap<String,String>として取得できます。デバッグ用途では役立ちますが、秘密情報を含む可能性があるため、ログへ丸ごと出す使い方は避けます。

import java.util.Map;

public class EnvList {
    public static void main(String[] args) {
        Map<String, String> env = System.getenv();
        System.out.println("JAVA_HOME=" + env.get("JAVA_HOME"));
        System.out.println("PATH exists=" + env.containsKey("PATH"));
    }
}

結果: 期待される出力は、JAVA_HOMEの値とPATHの有無です。Windowsでは環境によりPath表記で見える場合もあります。

この応用例は、うるう年判定のような小さなJavaプログラムにも転用できます。入力値や実行モードを環境変数へ切り出す考え方は、Javaでうるう年を判定する記事のような学習用コードにもなじみますし、これが一つの目安です。

注意点と対処法

Javaの環境変数でよく起きる問題は、パスの誤り、反映タイミングの誤解、複数JDKの混在です。これらはJavaコードの不具合に見えることもあるため、エラー文だけで判断せず、コマンドの検索順を確認するのが目安です。

変更を反映させる方法

Windowsでは、環境変数の画面やsetxで保存した後、新しいシェルを開いて確認すると覚えるとよいでしょう。macOSやLinuxでは、設定ファイルを保存した後にsourceで読み直すか、ターミナルを開き直します。

setx JAVA_HOME "C:path	ojdk-21"

結果: 期待される表示は、Windowsが値を保存したことを示すメッセージです。現在のシェルではなく、新しく開いたシェルでJAVA_HOMEを確認するのがポイントです。

echo %JAVA_HOME%

結果: 期待される出力は、保存したJDKパスです。空欄や古いパスなら、ユーザー環境変数とシステム環境変数のどちらを変更したか確認すると考えられます。

ただし、管理者権限で開いたシェルと通常ユーザーのシェルでは、参照する設定の見え方が変わる場合があります。そのため、Javaを実行する予定のユーザーで確認することが必要になるのが一般的です。

設定ミスを探す方法

設定ミスは、値そのものと検索順の両方から調べますが、覚えておくと役立つでしょう。たとえばJAVA_HOMEが正しくても、PATHの先頭に古いJDKのbinが残っていれば、古いJavaが起動されます。

set

結果: 期待される出力は、Windowsの環境変数一覧です。大量に表示されるため、JAVA_HOMEやPathだけに絞って確認すると扱いやすくなります。

echo $PATH

結果: 期待される出力は、Unix系シェルのコマンド検索パスです。区切り文字は:で、左側にあるディレクトリが先に検索されますし、ここを基本と考えるとよいでしょう。

逆に、ソースコード側のエスケープが原因でパス文字列が崩れる場合もあるのが現実的です。WindowsパスをJava文字列に書くときは、Javaのエスケープ処理も合わせて確認すると、の扱いを整理できます。

非推奨になりやすい考え方を避ける

環境変数をJavaコードから強引に書き換える発想は避けたほうがよいです。System.getenv()が返すMapは通常変更できず、リフレクションで内部構造へ触る方法はJDKの変更で壊れやすい設計になると言えるでしょう。

そのため、OSの環境変数はOSやシェルで設定し、Javaコードは値を読む側に寄せます。アプリケーション内の切替が必要なら、Properties、application.properties、コマンドライン引数、設定ファイルを併用すると整理できると整理できます。

Javaの環境変数のカスタマイズ方法

Javaの環境変数をカスタマイズする目的は、プロジェクト固有の差分をコードから分離することです。データベース接続先、外部APIのURL、ライブラリパスなどを分けると、同じサンプルコードを複数環境で動かしやすくなります。

独自の変数を追加する

独自変数は、名前の衝突を避けるためにアプリ名や組織名の接頭辞を付けます。MY_JAVA_LIBのような単純な名前でも学習用途には使えますが、実務寄りの設定ではMYAPP_JAVA_LIBのほうが意図を読み取りやすいです。

public class CustomEnv {
    public static void main(String[] args) {
        String myJavaLibPath = System.getenv("MY_JAVA_LIB");
        if (myJavaLibPath != null && !myJavaLibPath.isBlank()) {
            System.out.println("ライブラリパス: " + myJavaLibPath);
        } else {
            System.out.println("MY_JAVA_LIBは未設定です");
        }
    }
}

結果: 期待される出力は、MY_JAVA_LIBがあればその値、なければ未設定メッセージです。未設定時の分岐を入れると、初心者ガイドとしても原因を追いやすくなります。

export MY_JAVA_LIB='/opt/myapp/lib'

結果: 期待される状態は、現在のシェルでMY_JAVA_LIBが参照できることです。永続化する場合はシェル設定ファイルへ追記します。

こうしたカスタマイズは、継承やオーバーライドで構成を差し替える設計とも相性があるのが目安です。Javaのクラス設計を整理する場合は、Javaのオーバーライド解説も関連する読み物になると理解できます。

環境変数の最適化のヒント

環境変数は増やすほど柔軟になりますが、同時に前提条件も増えます。そのため、用途、初期値、未設定時の挙動を一覧化し、セットアップ手順と一緒に管理することが欠かせません。

具体的には、README.mdにJAVA_HOME、PATH、アプリ固有変数、起動例を書きますし、ここがポイントです。さらに、.env.exampleのようなテンプレートを用意すると、コーディングを始める前の環境差を減らせます。

ただし、秘密情報をそのままリポジトリへ置くのは避けますが、覚えておくと役立つでしょう。アクセストークンやパスワードは環境ごとの安全な保管場所で管理し、サンプルコードにはダミー値だけを置くのが一般的だと言えますが、これは押さえたい点です。

💡 Tips: JAVA_HOMEはJDKの場所、PATHはコマンド検索先、独自変数はアプリ設定というように役割を分けると、詳細解説を読まなくても設定の意図を追いやすくなります。

まとめ

Javaの環境変数は、JDKの場所をOSと開発ツールへ伝えるための設定です。PATHにbinを追加し、JAVA_HOMEにJDKのルートを入れるだけで、Javaのセットアップで起きる多くのつまずきを減らせます。

そのうえで、CLASSPATH、JAVA_OPTS、独自のプロジェクト変数を使い分けると、プログラミング環境を柔軟に管理できるのがポイントです。設定と確認を分け、サンプルコードで値を読み取る流れを持っておくと、コーディング中の不具合調査にもつながりますし、ここを基本と考えるとよいでしょう。

初心者ガイドとして特に押さえたいのは、Javaコードから環境変数を読むことと、OSの環境変数を永続化することは別の作業だという点です。応用例まで含めて整理すれば、開発環境、ビルド環境、実行環境の違いを扱いやすくなります。

※本記事は実在のエンジニア複数名で構成される Japanシーモア編集部が、AI支援を活用して作成・校正・公開しています。

関連記事

• Java List型完全ガイド！初心者でもマスターできる7つのステップ
• Javaアノテーションの12選！初心者から上級者まで徹底ガイド
• Javaでうるう年を判定！初心者でも分かる9ステップ解説
• Javaエスケープ処理の10ステップマスターガイド
• Javaでマスターする！オーバーライドのたった7つのステップ