「Java Gold の問題、正しく書けているつもりなのに間違える」「模試でひっかけに引っかかってばかり」——そう感じている方に向けた記事です。
Java Gold(1Z0-829 / Java SE 17)で受験者を落とす「ひっかけ」は、実はいくつかの決まった型に集約されます。なかでも最頻出は「このコードは(A)コンパイルエラー(B)実行時に例外(C)正常に動作、のどれか」を選ばせる問題です。丸暗記ではなく、コンパイル段階で弾かれるのか・実行して初めて落ちるのかを一手ずつ判定できるかが問われます。
この記事では、Java Gold と ORACLE MASTER Gold を保有する筆者が、実際に受験者がつまずきやすいひっかけを10パターンに整理し、先回りして落とし穴を潰していきます。断定や煽りは避け、仕様として確かなことと、注意して確認すべきことを分けて書きます。
※Java Goldの試験番号・対象バージョン・出題範囲・受験料・試験時間などの制度は改定されることがあります。本記事は執筆時点(2026年)で、試験番号 1Z0-829/対象 Java SE 17 を前提に解説しています。受験前には必ず Oracle 認定資格の公式サイトおよびピアソンVUEで、自分が受ける試験の最新情報をご確認ください。
- Java Gold のひっかけ問題に共通する「考え方」
- 落とされやすい10パターンの具体例と回避のコツ
- コンパイルエラーか実行時例外かを見抜く手順
- ひっかけに強くなる勉強法
Java Gold のひっかけは「型」で覚える
Java Gold のひっかけ問題は、知らない知識で殴ってくるより、「知っているはずの仕様の、細かい穴」を突いてくるのが特徴です。だからこそ、個別のコードを暗記するより、頻出する落とし穴の「型」を先に知っておくほうが効率的です。
以下、10パターンを順に見ていきます。いずれも「なぜそうなるか」を理由まで押さえるのがポイントです。
パターン1:コンパイルエラー vs 実行時例外の3択
Java Gold で最も多いのが、「このコードは(A)コンパイルエラー(B)実行時に例外がスローされる(C)正常に動作する、のどれか」を選ばせる形式です。まずコンパイルが通るかを判定し、通る場合だけ実行時の挙動を考える、という順番を徹底します。
典型的なひっかけは、次のような点でコンパイル段階の可否がすり替えられます。
- 到達不能コード(
returnの後ろに文がある等)→ コンパイルエラー - 検査例外(
IOExceptionなど)をthrowsもcatchもしていない → コンパイルエラー final変数への再代入 → コンパイルエラー- ローカル変数を初期化せずに使用 → コンパイルエラー
- 見抜く手順:①文法・型・例外処理でコンパイルが通るか →②通るなら実行時例外の有無 →③どちらもなければ正常動作
- 注意:選択肢に「コンパイルエラー」がある問題は、実行時の話に飛びつく前に必ずコンパイル可否を先に確認する
パターン2:var(ローカル変数型推論)の制約
var はローカル変数の型推論であり、使える場所が限られています。この制約を突くひっかけが頻出します。var が使えるのは、初期化子を伴うローカル変数・拡張for文の変数・for文の初期化部などに限られます。
var が使えない代表例は次のとおりで、いずれもコンパイルエラーになります。
- フィールド(インスタンス変数・静的変数)の宣言
- メソッドの引数・戻り値の型
- 初期化子なしの宣言(
var x;は不可) nullだけでの初期化(var x = null;は型を推論できず不可)- 配列初期化子の省略記法(
var arr = {1, 2, 3};は不可)
| 書き方 | 可否 | 理由 |
|---|---|---|
var i = 10; |
○ | 初期化子から int と推論 |
var list = new ArrayList<String>(); |
○ | 右辺から型が決まる |
var x; |
× | 初期化子がなく推論不可 |
var s = null; |
× | null だけでは型を決められない |
var arr = {1, 2, 3}; |
× | 配列初期化子の省略記法は不可 |
横にスクロールできます
var を使うのはアリでしたっけ?var、一部は型あり、という混在はコンパイルエラーになるんだ。ここも定番のひっかけだよ。- 要点:
varはローカル変数専用。フィールド・引数・戻り値には使えない - ラムダ:ラムダ引数の
varは全引数に付けるか全く付けないかの二択(混在不可)
パターン3:switch式(アロー構文)の網羅性とyield
Java SE 14 で標準化された switch 式は、値を返せる代わりに「網羅性」が求められます。式として値を代入に使う場合、すべての入力ケースを網羅していないとコンパイルエラーになります。アロー構文(case A -> ...)はフォールスルー(次のcaseへの流れ落ち)が起きない点も従来のswitch文と異なります。
ひっかけになりやすいポイントを整理します。
- switch 式(値を返す)は、
defaultを書くか、enumの全定数を尽くすなどして網羅していないとコンパイルエラー - アロー構文は
break不要でフォールスルーしない。従来のコロン構文(case A:)はフォールスルーする - アロー構文でブロック
{}から値を返すときはyieldを使う(returnではない) - アロー構文(
->)とコロン構文(:)を1つの switch 内で混在させることはできない
int n = switch (day) {
case MON, TUE -> 1;
case WED -> { yield 2; } // ブロックからは yield で返す
default -> 0; // 網羅のため default が要ることが多い
};
yield と return を取り違える問題、よく出ますよね。return と書くと、それはメソッドからの return になってしまってコンパイルエラーや意図しない挙動になる。switch 式のブロックから値を返すのは yield だ、と紐づけておこう。- 要点:switch 式は網羅必須/アロー構文はフォールスルーしない/ブロックからの返却は
yield - 注意:アロー構文とコロン構文の混在は不可
パターン4:Stream は終端操作がないと動かない・再利用できない
Stream API は「中間操作」だけでは何も実行されず、forEach や collect などの「終端操作」が呼ばれて初めて処理が走ります(遅延評価)。さらに、一度終端操作を行った Stream は再利用できず、再度操作すると IllegalStateException がスローされます。
ここを突くひっかけは次のようなものです。
filterやmapだけ書いて終端操作がない → 何も出力されない(副作用が起きない)- 同じ Stream 変数に対して 2 回目の終端操作を呼ぶ → 実行時に
IllegalStateException peekは中間操作なので、終端操作がなければ実行されない
Stream<String> s = List.of("a", "b").stream();
s.forEach(System.out::println); // 1回目:OK
s.forEach(System.out::println); // 2回目:IllegalStateException(実行時例外)
forEach はコンパイルは通る。落ちるのは実行時だ。パターン1の『まずコンパイル可否、次に実行時』の順で見れば、正しく(C)ではなく(B)を選べる。- 要点:中間操作は遅延評価。終端操作がないと処理は走らない
- 注意:終端操作済みの Stream の再操作は実行時に
IllegalStateException
パターン5:Optional の生成と取り出しの罠
Optional は「値があるかもしれない箱」ですが、生成と取り出しの両方にひっかけが仕込まれます。Optional.of(null) は NullPointerException をスローし、空の Optional に対する get() は NoSuchElementException をスローします。
押さえておきたい点を整理します。
Optional.of(x):xがnullだと実行時にNullPointerExceptionOptional.ofNullable(x):xがnullなら空の Optional を返す(NPEにならない)- 空の Optional に
get()→NoSuchElementException orElse(v)は常にvを評価する。orElseGet(supplier)は空のときだけ Supplier を評価する
| メソッド | 空のときの挙動 |
|---|---|
get() |
NoSuchElementException をスロー |
orElse(v) |
v を返す(v は常に評価される) |
orElseGet(() -> ...) |
Supplier を実行して返す(空のときだけ評価) |
orElseThrow() |
NoSuchElementException をスロー |
横にスクロールできます
of と ofNullable の取り違え、やりがちです。null かもしれない値を包むときは ofNullable。null は絶対に来ないと保証できるときだけ of。試験では「Optional.of(null) の結果は?」と聞いて、実行時のNPEを選ばせてくることが多いよ。- 要点:
ofはnullでNPE、ofNullableは空を返す。空へのget()はNoSuchElementException - 注意:
orElseは引数を常に評価、orElseGetは空のときだけ評価
パターン6:オートボクシングと Integer キャッシュ
Integer などのラッパークラスには、一定範囲の値をキャッシュする仕組みがあり、== 比較の結果が直感と食い違うひっかけになります。Integer は一般に -128〜127 の範囲をキャッシュするため、この範囲内の同じ値は == で true、範囲外は別インスタンスになり false になり得ます。
Integer a = 127, b = 127;
Integer c = 128, d = 128;
System.out.println(a == b); // true(キャッシュ範囲内)
System.out.println(c == d); // false になり得る(範囲外)
System.out.println(c.equals(d)); // true(値の比較)
== が値によって true だったり false だったり…混乱します。equals、== は参照比較」と割り切るのが大事なんだ。試験は 127 と 128 をわざと並べて、キャッシュ境界を知っているか試してくる。値の比較なら必ず equals を使う、と覚えておけば引っかからないよ。- 要点:
Integerは概ね -128〜127 をキャッシュ。範囲外は==がfalseになり得る - 注意:ラッパーの値比較は必ず
equals。==は参照比較になる
パターン7:try-with-resources のクローズ順序と finally
try-with-resources では、複数のリソースは「宣言と逆順」でクローズされます。また、finally ブロック内で return すると、try 内の return や例外を上書きしてしまう、という古典的なひっかけも健在です。
整理しておきたい点です。
- try-with-resources のリソースは、生成順とは逆順で
close()される - クローズ対象は
AutoCloseable(またはCloseable)を実装している必要がある - Java 9 以降は、実質的に final なローカル変数を try-with-resources のリソースとして指定できる
finally内のreturnは、try 内のreturn値や例外を握りつぶす(アンチパターンとして出題される)
try (var a = new Res("A"); var b = new Res("B")) {
// 使う
} // close は B → A の順(逆順)
- 要点:リソースのクローズは宣言の逆順。対象は
AutoCloseable実装が必須 - 注意:
finally内returnは try の結果・例外を上書きする
パターン8:ジェネリクスのワイルドカード(PECS)
ジェネリクスのワイルドカードは、? extends と ? super で「できること」が変わり、これを突くひっかけが定番です。List<? extends Number> は要素を取り出せますが、(null を除いて)要素を追加できません。逆に List<? super Integer> は Integer を追加できますが、取り出しは Object としてになります。
この使い分けは PECS(Producer Extends, Consumer Super) という語呂で整理できます。
? extends T(Producer=取り出す側):読み取り(get)はできるが、追加(add)は原則できない? super T(Consumer=入れる側):Tの追加(add)はできるが、取り出しはObject型になる
List<? extends Number> src = List.of(1, 2, 3);
Number n = src.get(0); // OK:取り出しはできる
// src.add(4); // コンパイルエラー:追加はできない
List<? super Integer> dst = new ArrayList<Number>();
dst.add(10); // OK:Integer は追加できる
Object o = dst.get(0); // 取り出しは Object 型
extends なのに add できないの、直感に反します。? extends Number は「Number の何かのサブ型のリスト」で、Integer かもしれないし Double かもしれない。だから何を add していいか決められない。だから読み取り専用に近くなる。PECS の語呂で「取り出すなら extends、入れるなら super」と覚えるのが速いよ。- 要点:
? extendsは読み取り向き(追加不可)、? superは追加向き(取り出しは Object) - 注意:
? extendsへのaddはコンパイルエラー(nullを除く)
パターン9:関数型インタフェースの引数と戻り値
java.util.function パッケージの標準関数型インタフェースは、引数と戻り値の「形」を取り違えさせるひっかけが多いです。それぞれの抽象メソッドのシグネチャを正確に覚えているかが問われます。
主要なものを整理します。
| インタフェース | 抽象メソッド | 意味 |
|---|---|---|
Supplier<T> |
T get() |
引数なしで T を返す |
Consumer<T> |
void accept(T) |
T を受け取り、戻り値なし |
Function<T,R> |
R apply(T) |
T を受け取り R を返す |
Predicate<T> |
boolean test(T) |
T を受け取り boolean を返す |
UnaryOperator<T> |
T apply(T) |
T を受け取り同じ T を返す |
BiFunction<T,U,R> |
R apply(T,U) |
2引数を受け取り R を返す |
横にスクロールできます
Supplier と Consumer を逆に覚えていました。Supplier は「供給する側」だから引数なしで値を返す。Consumer は「消費する側」だから値を受け取って何も返さない。名前の意味と結びつけると取り違えにくい。試験では、ラムダの形(() -> x なのか x -> {} なのか)から、当てはまるインタフェースを選ばせてくるよ。- 要点:Supplier=引数なしで返す/Consumer=受け取って返さない/Function=受け取って返す/Predicate=booleanを返す
- 注意:ラムダの形とシグネチャが一致しないとコンパイルエラー
パターン10:sealed・record・インタフェースの新メソッド
Java SE 17 で標準化された sealed クラスや record、そしてインタフェースの default/static/private メソッドも、細かい制約を突くひっかけが出ます。新しめの言語機能ほど「書ける形」を限定する仕様があり、そこが狙われます。
押さえておきたい制約です。
sealedクラス/インタフェース:permitsで許可したサブ型のみが継承・実装でき、そのサブ型はfinal・sealed・non-sealedのいずれかを明示する必要があるrecord:暗黙にfinalで、コンポーネントに対応するprivate finalフィールドとアクセサが自動生成される。インスタンスフィールドの追加宣言はできない- インタフェースの
privateメソッド:default/staticメソッドから共通処理を切り出すために使える(実装クラスからは呼べない) - インタフェースの
defaultメソッドは多重継承で衝突すると、実装クラスでのオーバーライドが必要になる場合がある
- 要点:sealed は permits で継承先を限定、サブ型は final/sealed/non-sealed を明示。record は暗黙 final でインスタンスフィールド追加不可
- 注意:インタフェースの private メソッドは default/static からの共通化用(外部からは呼べない)
ひっかけに強くなる勉強法
ひっかけ対策の核心は、「動くコードを書く力」ではなく「他人が書いたコードの落ちどころを一手ずつ読む力」を鍛えることです。Java Gold と ORACLE MASTER Gold を取得した筆者の経験からも、ここが得点の分かれ目でした。
具体的には、次の進め方が有効だと考えています。
- 必ず手を動かして確かめる:ひっかけ問題は、実際に短いコードを書いて
javac/javaで挙動を確かめると、記憶への残り方がまったく違います。「コンパイルで落ちるのか、実行で落ちるのか」を自分の目で見る経験が効きます。 - 3択(コンパイル/実行時/正常)で自問する癖:問題を読んだら、まず「コンパイルは通る?」を先に判定し、通る場合だけ実行時を考える。パターン1の手順を毎問なぞります。
- 間違えた問題は「なぜ引っかかったか」を言語化する:
varの制約なのか、Stream の再利用なのか、ワイルドカードなのか、落とし穴の「型」でメモを分類すると、同種の問題に強くなります。 - 新機能(record・sealed・switch式・text block)は仕様の境界を重点的に:Java SE 17 で入った機能ほど「できない書き方」が問われます。「できること」より「できないこと」を意識して覚えます。
⚠️ 出題範囲・出題傾向・合格ラインは改定されることがあります。本記事は執筆時点での傾向整理であり、合格を保証するものではありません。学習教材は、対象バージョン(Java SE 17 / 1Z0-829)に対応した最新版を選び、最終的な範囲は Oracle の公式情報でご確認ください。勉強法の全体像はJava 資格の取得順序、データベース側の Gold はORACLE MASTER Gold の勉強法と難易度もあわせてどうぞ。
Java Gold ひっかけ問題のよくある質問(FAQ)
Java Gold のひっかけ問題にはどんなパターンが多いですか?
var・switch式・Stream・Optional・ジェネリクスのワイルドカード・try-with-resources の周辺で、細かい仕様の穴を突いてきます。コードを丸暗記せず、コンパイル段階で弾かれるのか実行して初めて落ちるのかを一手ずつ判定する習慣が有効です。Java Gold は暗記だけで合格できますか?
Java Gold の試験番号とバージョンは何ですか?
var と switch式では、どちらのひっかけが出やすいですか?
var は「使える場所の制約(フィールド・引数・戻り値には不可、null単独不可、ラムダ引数の混在不可)」、switch式は「網羅性・フォールスルーしないアロー構文・ブロックからは yield」が狙われます。両方とも「できない書き方」を覚えるのが対策になります。ひっかけ対策に一番効いた勉強法は何ですか?
Integer のキャッシュや Stream の再利用エラーのような、実行時に初めて分かる挙動が記憶に残りにくいためです。間違えた問題を落とし穴の「型」で分類してメモするのも、同種の問題への耐性を上げるのに役立ちました。まとめ:Java Gold ひっかけ問題の攻略ポイント
Java Gold(1Z0-829 / Java SE 17)のひっかけ問題を整理します。
- 最頻出は3択:「コンパイルエラー/実行時例外/正常動作」を、コンパイル可否 → 実行時、の順で一手ずつ判定する
var・switch式・Stream・Optional・ジェネリクス:いずれも「できない書き方」「境界の挙動」が狙われる。ラッパーの==と Integer キャッシュ、try-with-resources の逆順クローズも定番- 新機能(record・sealed・関数型インタフェース):仕様の制約を突かれる。「できること」より「できないこと」を意識する
- 勉強法:手を動かして挙動を確かめ、間違いを落とし穴の「型」で分類する。暗記より「読む力」を鍛える
ひっかけは知識量より「読み方の型」で防げる部分が大きい、というのが筆者の率直な実感です。10パターンを頭の引き出しに入れておけば、初見の問題でも「これはあの型だ」と気づけるようになります。
なお、試験番号・対象バージョン・出題範囲・受験料などの制度は改定されることがあります。受験前には必ず Oracle 認定資格およびピアソンVUEの公式サイトで最新情報を確認してください。Java 資格をどの順で取るかはJava 資格の取得順序、データベース側の Gold はORACLE MASTER Gold の勉強法と難易度、資格全体の地図を描きたい方はエンジニアのスキルアップ・ロードマップも参考になります。
免責:本記事は筆者(Java Gold/ORACLE MASTER Gold 保有)の学習経験および執筆時点で一般に公開されている情報にもとづく情報提供であり、特定の合格・成果を保証するものではありません。掲載したコード挙動の説明は Java SE 17 / 1Z0-829 を前提とした一般的な理解にもとづくもので、実際の出題・挙動は環境やバージョンによって異なる場合があります。試験番号・対象バージョン・出題範囲・受験料・試験時間などの認定制度は改定されることがあります。受験前には必ず Oracle 認定資格およびピアソンVUEの公式サイトで、自分が受ける試験の最新情報をご確認ください。最終的な判断はご自身の責任で行ってください。
