{
  "assessmentTests": {
    "java_test": {
      "name": "Javaテスト",
      "desc": "コア構文、OOP、コレクション、ジェネリクス、例外、並行処理に関する30のシナリオ問題——あなたのJavaスキルが、求人票の『Java習熟度』と一致しているかを判定します。",
      "recommendation": "あなたのJavaスキルプロフィール",
      "results": {
        "beginner": {
          "name": "初級者",
          "desc": "クラスとメソッドは書けますが、外した問題は構文よりも、参照と初期値に集中しています——String == vs .equals、new String(\"x\")が文字列プールを再利用しない理由、数値フィールドのデフォルト値とwrapperフィールドの違い。これはJavaが下手という話ではなく、参照とプリミティブがメモリ下でどう動くか、試行錯誤で学んだ人が引っかかる特定のルールです。仕事で重要なのは、こうしたルール一つひとつが、コンパイルされて走るコードが静かに間違った値を返す場所だからです。",
          "recommendation": "3つのテーマから始めましょう、この順で。String オブジェクトで== を使うと参照を比較する理由（そして.equalsがほぼ常に必要な理由）、int のオーバーフロー時に例外ではなく静かにラップアラウンドする理由、初期化されていないIntegerフィールドがnullなのに対してintフィールドが0になる理由。OracleのJava公式チュートリアルとBaeldungは、どちらも3つすべてを実行可能な例でカバーしています。"
        },
        "intermediate": {
          "name": "中級者",
          "desc": "日常的なアプリケーションコードは快適にこなします——クラス、コレクション、ストレートな制御フロー——ルーチンな機能開発で足を引っ張られることはありません。ここから上級への差は、主としてJavaのルールが並行処理やジェネリクスと相互作用するときに何が起きるかです。静的メソッドは宣言された型で解決される。HashMapの反復順序が黙って依存していた。ループの途中でアイテムを削除するとConcurrentModificationExceptionが出る。こういったバグは、ざっと眺めたくらいでは見つかりませんが、特定のランタイム条件のときに初めて表れます。",
          "recommendation": "コンパイラの静的な見方と実際に走るコードの違いに焦点を当てましょう。宣言された型で呼ばれた静的メソッドの隠蔽、HashMapが反復順序を保証しない理由、ループの途中でリストを直接修正するとConcurrentModificationExceptionが出る理由。次にジェネリクス削除（erasure）——これはコレクション個々に知っている人でも引っかかるものです。"
        },
        "advanced": {
          "name": "上級者",
          "desc": "これは、ほぼすべての求人票が『Java強い』とはこのレベルを指しています。staticブロック、インスタンスブロック、複数のコンストラクタを持つクラスを見て、実行順序を予測できます。finallyブロックが静かにtryブロックの戻り値を捨てる理由がわかります。finally-closeの手動よりもtry-with-resourcesに手を伸ばすことができます。このランクと最上位を分ける要素は、他のスレッドと他のインターフェースが接する側面です。synchronizedが正確に何をロックするか、volatileが何を保証しないか、デフォルトメソッドの競合がどう解決されるか、を知ること。",
          "recommendation": "他のスレッドと他のインターフェースも接するコードを保護する側面に進みましょう。synchronized インスタンスメソッドがロックするもの対synchronized staticメソッド、volatileが見える性を保証するが counter++ のアトミック性は保証しない理由、Javaがデフォルトメソッドのダイアモンド競合を強制的に解決させる方法。BaeldungとJava Concurrency in PracticeのJavaメモリモデルに関する資料が、次のステップに最適です。"
        },
        "expert": {
          "name": "エキスパート",
          "desc": "すべてのセクション——コア構文と型、OOP機構とスコープ、コレクションとジェネリクス、例外と並行処理とイディオム——で最高点を取りました。実務上、それは初めて見た誰かのクラスを渡されて、コンパイルエラーや実行時例外や静かに間違った値が返ってくる理由を説明できるということ。これはより難しく、より価値ある技能です。このレベルでは、言語そのものが仕事の制限になることはまれです。制限は通常、並行処理の設計か、その下にあるデータの形です。",
          "recommendation": "リターンは今、設計と診断の側にあります。ハングがデッドロックだと仮定する前にスレッドダンプを読むこと、synchronized、java.util.concurrent ロック、アトミクスをトレードオフとしてではなくデフォルトとして選ぶことではなく、ストリームパイプラインを目的で遅延させることをコントロールすること。採用面接でスクリーニングされている場合は、Java機能の名前を挙げるのではなく、本番環境で見つけた結合ファンアウトまたはmissed happens-before edgeのようなコンカレンシーバグの説明をしてください。それは語彙ではなく、推論の力を示します。"
        }
      },
      "questions": [
        {
          "question": "2つのStringオブジェクトを作成します: String a = new String(\"cat\"); String b = new String(\"cat\"); a == b は何に評価されますか？",
          "options": [
            {
              "icon": "",
              "label": "true——同じ文字を持つString リテラルは常に同じオブジェクト"
            },
            {
              "icon": "",
              "label": "true——new String(...) は文字列プールを再利用するため、同じテキストは常に1つのオブジェクトを共有"
            },
            {
              "icon": "",
              "label": "コンパイルエラー——== はString オブジェクトの比較に使えない"
            },
            {
              "icon": "",
              "label": "false——new String(...) は常にヒープに新しいオブジェクトを割り当てるため、== は2つの異なる参照を比較しますが、.equals(b) はtrueを返す"
            }
          ]
        },
        {
          "question": "Integer x = 100; Integer y = 100; System.out.println(x == y); その後、Integer x2 = 200; Integer y2 = 200; System.out.println(x2 == y2); 2行は何を出力しますか？",
          "options": [
            {
              "icon": "",
              "label": "true でも true——オートボックス Integer オブジェクトは値に関わらず常にキャッシュされる"
            },
            {
              "icon": "",
              "label": "false でも false——== Integer オブジェクトでは常に参照比較であり、等しい値は決してマッチしない"
            },
            {
              "icon": "",
              "label": "true でも false、ただし200がバイトをオーバーフローしたときだけ——キャッシュ境界は-128..127に無関係"
            },
            {
              "icon": "",
              "label": "true でも false——オートボックス Integer 値の-128から127はキャッシュされて共有されるため、100は1つのオブジェクトを再利用しますが、200はキャッシュ外で2つの別々のオブジェクトにオートボックスされる"
            }
          ]
        },
        {
          "question": "int max = Integer.MAX_VALUE; System.out.println(max + 1); 何が起きますか？",
          "options": [
            {
              "icon": "",
              "label": "整数オーバーフロー時にArithmeticException をスロー"
            },
            {
              "icon": "",
              "label": "Integer.MAX_VALUE をもう一度出力——JavaはMATの最大値でクランプ"
            },
            {
              "icon": "",
              "label": "Integer.MIN_VALUE を出力——int 算算術は例外をスロー代わりにオーバーフロー時に静かにラップアラウンド"
            },
            {
              "icon": "",
              "label": "コンパイルエラー——コンパイラはオーバーフロー前に検出"
            }
          ]
        },
        {
          "question": "System.out.println(0.1 + 0.2 == 0.3); これは何を出力し、なぜですか？",
          "options": [
            {
              "icon": "",
              "label": "false——0.1、0.2、0.3は二進浮動小数点では正確に表現できず、合計は丸め誤差を持ち、ビット単位で0.3と等しくない"
            },
            {
              "icon": "",
              "label": "true——Javaは比較前に二重演算を最も近い表現可能な十進数に丸める"
            },
            {
              "icon": "",
              "label": "true——2つの小数位数を持つ値の加算は常に正確"
            },
            {
              "icon": "",
              "label": "例外をスロー——== はJavaのdoubleに対して定義されていない"
            }
          ]
        },
        {
          "question": "クラスが初期化子のない2つのインスタンスフィールドを宣言します: int count; と Integer total; コンストラクタが実行される前に、それらのデフォルト値は何ですか？",
          "options": [
            {
              "icon": "",
              "label": "どちらも0にデフォルト——Integer はフィールド初期化時に int にオートボックス"
            },
            {
              "icon": "",
              "label": "count は0で total は0、オートボックスは最初に読むときに自動的に行われる"
            },
            {
              "icon": "",
              "label": "count は0で total はnull——プリミティブ数値フィールドはゼロにデフォルトしますが、初期化されていないwrapper参照フィールドは他のオブジェクト参照のようにnullにデフォルト"
            },
            {
              "icon": "",
              "label": "どちらも明示的に割り当てられるまでnullにデフォルト——Javaには暗黙的な数値デフォルトはない"
            }
          ]
        },
        {
          "question": "ループが1000回実行され、毎回String result で result += \"x\"; を行います。その下で何が起きていますか？",
          "options": [
            {
              "icon": "",
              "label": "既存のString オブジェクトの内部文字配列がその場所で拡張される"
            },
            {
              "icon": "",
              "label": "Javaは自動的に連結をバッチ処理し、1つの最終String オブジェクトのみを割り当てる"
            },
            {
              "icon": "",
              "label": "1000反復全体で共有される単一のStringBuilder.append() 呼び出しにコンパイルされ、反復ごとに余分なオブジェクトは割り当てられない"
            },
            {
              "icon": "",
              "label": "ブランド新しいString オブジェクトが作成され result は新しいオブジェクトを指すように再割り当てされます——String は不変で += はその場所で修正できません"
            }
          ]
        },
        {
          "question": "final List<String> names = new ArrayList<>(); 次のどれが真ですか？",
          "options": [
            {
              "icon": "",
              "label": "names.add(\"Ana\") はコンパイルして正常に動作——final はnames参照自体の再割り当てのみを防ぎ、指すオブジェクトの変更ではない"
            },
            {
              "icon": "",
              "label": "names.add(\"Ana\") はコンパイルエラー——final はリスト自体を変更不可にする"
            },
            {
              "icon": "",
              "label": "リストはfinal で宣言されているため、並行書き込みに対してスレッドセーフ"
            },
            {
              "icon": "",
              "label": "ローカル変数上のfinal には、型も不変と宣言されない限り効果がない"
            }
          ]
        },
        {
          "question": "int[] a = {1, 2, 3}; int[] b = {1, 2, 3}; System.out.println(a == b); System.out.println(Arrays.equals(a, b)); 2行は何を出力しますか？",
          "options": [
            {
              "icon": "",
              "label": "false でも true——== は配列参照（2つの異なる配列オブジェクト）を比較し、Arrays.equals は要素を比較"
            },
            {
              "icon": "",
              "label": "true でも true——同一の内容を持つ配列はJavaの同じオブジェクト"
            },
            {
              "icon": "",
              "label": "false でも false——Arrays.equals はプリミティブint 配列ではなく、オブジェクト配列に対してのみ機能"
            },
            {
              "icon": "",
              "label": "true でも false——配列上の== は内容を比較し、Arrays.equals は冗長"
            }
          ]
        },
        {
          "question": "void show(Object o) { print(\"Object\"); } void show(String s) { print(\"String\"); } Object ref = \"hello\"; show(ref); どのオーバーロードが実行され、なぜですか？",
          "options": [
            {
              "icon": "",
              "label": "show(String) が実行される——Javaはオーバーロードを選ぶ前にオブジェクトの実際のランタイムクラスを検査する"
            },
            {
              "icon": "",
              "label": "show(Object) が実行される——オーバーロード解決はコンパイル時に変数の宣言された型を使って決定され、参照するオブジェクトの実際のランタイム型ではない"
            },
            {
              "icon": "",
              "label": "コンパイルエラー——より具体的なオーバーロードが存在する場所にObject は渡せない"
            },
            {
              "icon": "",
              "label": "両方のメソッドが実行される——Javaはすべてのマッチを試してオーバーロードを解決"
            }
          ]
        },
        {
          "question": "Baseクラスは static void greet() { print(\"Base\"); } を持ちます。Derived はBaseを拡張し、static void greet() { print(\"Derived\"); } も宣言します。Base ref = new Derived(); ref.greet(); を書きます。何が出力されますか？",
          "options": [
            {
              "icon": "",
              "label": "Derived——静的メソッドはインスタンスメソッドのようにオーバーライドされ、実際のオブジェクトのランタイム型に従う"
            },
            {
              "icon": "",
              "label": "コンパイルエラー——静的メソッドはインスタンス参照を通して呼ばれない"
            },
            {
              "icon": "",
              "label": "Base——静的メソッドはポリモーフィックではなく、参照を通した呼び出しはコンパイル時の参照の宣言された型で解決され、オブジェクトの実際の型ではない"
            },
            {
              "icon": "",
              "label": "BaseとDerivedの両方が出力される——呼び出しは隠蔽版と隠す版の両方に解決される"
            }
          ]
        },
        {
          "question": "メソッド内で、int count = 0; を書き、その後別のメソッドに渡されるラムダ内からcount を参照してみます。これをコンパイルするために count について何が真でなければなりませんか？",
          "options": [
            {
              "icon": "",
              "label": "count は有効にfinal でなければならない——初期値の後に再割り当てされない——ラムダは可変ローカル変数への生きた参照ではなくスナップショットをキャプチャ"
            },
            {
              "icon": "",
              "label": "何もない——任意のローカル変数はラムダ内から自由に読み取り、再割り当てされる"
            },
            {
              "icon": "",
              "label": "count はvolatile として宣言されなければならない——ラムダは常に最新の値を見るため"
            },
            {
              "icon": "",
              "label": "count はフィールドでなければならない——ラムダはローカルをまったくキャプチャできない"
            }
          ]
        },
        {
          "question": "void rename(StringBuilder sb) { sb = new StringBuilder(\"new\"); } は StringBuilder original = new StringBuilder(\"old\"); rename(original); として呼ばれます。呼び出し後にoriginal は何ですか？",
          "options": [
            {
              "icon": "",
              "label": "\"new\" になる——オブジェクトはJavaで参照によって渡され、パラメータを再割り当てすると呼び出し者の変数も変わる"
            },
            {
              "icon": "",
              "label": "\"new\" になります。ただしStringBuilder のような可変型の場合に限ります。不変型の場合はそうではない"
            },
            {
              "icon": "",
              "label": "\"old\" のまま——Javaは参照自体を値によって渡すため、メソッド内のパラメータの再割り当ては呼び出し者の参照のローカルコピーのみを指し直し、元の呼び出し者は触れたままになる"
            },
            {
              "icon": "",
              "label": "メソッド内でsb が再割り当てされたため、実行時例外をスロー"
            }
          ]
        },
        {
          "question": "クラスは静的初期化子ブロック、インスタンス初期化子ブロック、コンストラクタを持ち、その順番でソースされます。このクラスの2つのオブジェクトを連続して作成します。どの順序でこれらが実行されますか？",
          "options": [
            {
              "icon": "",
              "label": "静的ブロックは正確に一度、クラスが最初にロードされるときに実行されます。次に、オブジェクトごとに、インスタンスブロックが実行されて、その後コンストラクタ本体が実行される"
            },
            {
              "icon": "",
              "label": "3つすべてが新しく実行される、作成されたすべての単一オブジェクトに対して、ソース順で"
            },
            {
              "icon": "",
              "label": "コンストラクタは各オブジェクトに対して最初に実行され、その後インスタンスブロック、その後静的ブロックが最後に一度実行される"
            },
            {
              "icon": "",
              "label": "静的ブロックは各オブジェクトに対して一度実行され、インスタンスブロックの前の直前に"
            }
          ]
        },
        {
          "question": "クラスは void log(String s) と void log(String... args) を持ちます。log(\"hi\") を呼ぶ。どちらが実行されますか？",
          "options": [
            {
              "icon": "",
              "label": "log(String... args)——可変長引数オーバーロードは両方が該当する場合、常に優先"
            },
            {
              "icon": "",
              "label": "コンパイルエラー——呼び出しは2つのオーバーロード間で曖昧"
            },
            {
              "icon": "",
              "label": "log(String s)——固定アリティオーバーロードが正確にマッチするとき、Javaは常に可変長引数オーバーロード（最後の手段としてのみ使用される）よりそれを優先"
            },
            {
              "icon": "",
              "label": "ソースファイルで最初に宣言されたもの"
            }
          ]
        },
        {
          "question": "コンストラクタの最初の行がthis(0); を呼び出して同じクラスの別のコンストラクタに委譲します。これはどこに現れることが許されますか？",
          "options": [
            {
              "icon": "",
              "label": "コンストラクタ本体のどこでも、オブジェクトが返される前に実行される限り"
            },
            {
              "icon": "",
              "label": "コンストラクタの最初の文としてのみ——this() （またはsuper()）は最初の行でなければならず、コンストラクタはthis() とsuper() の両方を呼べない"
            },
            {
              "icon": "",
              "label": "最後の文としてのみ、すべてのフィールド初期化が完了した後"
            },
            {
              "icon": "",
              "label": "delegateキーワードを使用して明示的に委譲としてマークされたコンストラクタのみ"
            }
          ]
        },
        {
          "question": "リストに極めて頻繁に前に要素が挿入され、ランダムアクセス読み取りは稀です。どちらが構造的により適合し、なぜですか？",
          "options": [
            {
              "icon": "",
              "label": "ArrayList——その連続バッキングアレイは前挿入を含むすべての操作を、リンク構造よりも高速にする"
            },
            {
              "icon": "",
              "label": "同じパフォーマンス——両方ともList インターフェースを実装し、同じ時間保証"
            },
            {
              "icon": "",
              "label": "LinkedList——前への挿入はO(1)なのは単にノードを再リンクするだけだから、一方ArrayListはすべての既存要素を1つシフトアップする必要があり、前挿入O(n)になる"
            },
            {
              "icon": "",
              "label": "LinkedList——ランダムアクセスを O(1) でサポート。一方ArrayListはサポートしない"
            }
          ]
        },
        {
          "question": "5つのエントリを特定の順序で平野のHashMap に挿入してから、for-eachループで反復します。エントリはどの順序で出てきますか？",
          "options": [
            {
              "icon": "",
              "label": "エントリが挿入された順序と同じ——JavaマップはMaps常に挿入順序を保持"
            },
            {
              "icon": "",
              "label": "保証された順序なし——HashMapの反復順序はハッシュバケット配置に依存し、挿入順序ではなく、実行間で変わることさえあります。LinkedHashMap が挿入順序を保持します"
            },
            {
              "icon": "",
              "label": "キーでソートされた——TreeMap が動作する方法と同じように自動的に"
            },
            {
              "icon": "",
              "label": "挿入順序の逆、HashMapがスタックを内部で使用するため"
            }
          ]
        },
        {
          "question": "平野のjava.util.HashMap はいくつのnull キーを一度に保持でき、いくつのnull 値を保持できますか？",
          "options": [
            {
              "icon": "",
              "label": "null キーも null 値も許可されない——あらゆるMapの実装"
            },
            {
              "icon": "",
              "label": "最大1つのnull キー、任意の数のnull 値——HashMap は単一のnull キーを許可し、Hashtable はどちらも許可しない"
            },
            {
              "icon": "",
              "label": "無制限のnull キーと無制限のnull 値——null は他のキーのように扱われる"
            },
            {
              "icon": "",
              "label": "最大1つのnull キーと最大1つのnull 値——両方は最大1つに帽子"
            }
          ]
        },
        {
          "question": "for-eachループでリストを反復して、ループ本体内からリストに直接list.remove(item) を呼び出します。いくつかの要素に対してですが、すべてではありません。何が起きますか？",
          "options": [
            {
              "icon": "",
              "label": "正常に動作し、意図した要素のみを削除"
            },
            {
              "icon": "",
              "label": "削除された要素の後の要素を静かにスキップしますが、それ以外はエラーなく完了"
            },
            {
              "icon": "",
              "label": "ループがリストの古い要素数に到達すると、IndexOutOfBoundsException をスロー"
            },
            {
              "icon": "",
              "label": "ConcurrentModificationException をスロー——暗黙的なイテレータが歩いている間にリスト構造を直接修正することは検出されて拒否されます。Iterator.remove() を代わりに使用する必要があります"
            }
          ]
        },
        {
          "question": "実行時で、List<String> list が与えられ、反射またはinstanceof 経由でジェネリック型パラメータについて実際に何を判定できますか？",
          "options": [
            {
              "icon": "",
              "label": "list.getElementType() を呼んでString.class を実行時に取得できます"
            },
            {
              "icon": "",
              "label": "instanceof List<String> はコンパイルされ、要素型を正しく検査"
            },
            {
              "icon": "",
              "label": "JVMは型パラメータを隠蔽されたメタデータとして保存し、list.getGenericType() 経由でアクセス可能"
            },
            {
              "icon": "",
              "label": "何もない——ジェネリック型情報はコンパイル時に削除されるため、実行時にオブジェクトはList であり、それがList<String> か List<Integer> で宣言されたかを復元する方法はない"
            }
          ]
        },
        {
          "question": "switch (day) { case 1: case 2: print(\"Weekday\"); break; case 6: print(\"Saturday\"); case 7: print(\"Sunday\"); break; default: print(\"?\"); } day が6の場合、何が出力されますか？",
          "options": [
            {
              "icon": "",
              "label": "Saturday のみ——switchの各caseブロックは常に独自のprint文の後に停止"
            },
            {
              "icon": "",
              "label": "Sunday のみ——マッチングはcase 6で開始されますが、breakの前の最後のマッチングラベルのみが実行"
            },
            {
              "icon": "",
              "label": "何も出力されない——day 6には独自のbreakで直接下にあるマッチングcaseがない"
            },
            {
              "icon": "",
              "label": "SaturdayとSunday——case 6はbreakがないため、実行は次のcaseのコードに流れ込み、breakの後に止まる"
            }
          ]
        },
        {
          "question": "Productクラスは単一の明白な「自然な」価格でのソート順序を必要とし、さらにコードベースのさまざまな場所で名前またはストック水準でもソートできます。どの組み合わせが正しい設計ですか？",
          "options": [
            {
              "icon": "",
              "label": "Comparable<Product> を3回個別に実装し、1つのオーダリング、呼び出し者が実行するcompareToを選択"
            },
            {
              "icon": "",
              "label": "Comparable<Product> を自然な価格オーダリングに対して実装し、名前とストック水準オーダリング用の個別Comparator<Product> インスタンスを書く"
            },
            {
              "icon": "",
              "label": "すべてのオーダリング（価格を含む）に対してのみComparator を使用し、Comparable は利点がないため"
            },
            {
              "icon": "",
              "label": "3つのオーバーロードされたcompareTo メソッド（オーダリングごとに1つ）を追加して、Comparable のみを使用"
            }
          ]
        },
        {
          "question": "メソッドがnew FileReader(path) を呼び出し、IOException をスロー宣言します。IOException はException を拡張し、RuntimeException ではありません。これをコンパイルするために何をする必要がありますか？",
          "options": [
            {
              "icon": "",
              "label": "何もない——コンパイラはこれをRuntimeException を拡張する例外に対してのみ強制"
            },
            {
              "icon": "",
              "label": "try/catch 内でIOException をキャッチするか、独自のメソッドでthrows IOException を宣言——チェック例外は、unchecked RuntimeException サブクラスと異なり、明示的に処理または伝播される必要があります"
            },
            {
              "icon": "",
              "label": "RuntimeException のtry/catch でコールをラップ——IOException は最新のJavaで自動的にunchecked"
            },
            {
              "icon": "",
              "label": "メソッドをstatic として宣言——静的メソッドはチェック例外処理を免除"
            }
          ]
        },
        {
          "question": "try (Resource a = new Resource(\"A\"); Resource b = new Resource(\"B\")) { ... } はAutoCloseable を実装する2つのリソースを使用します。try ブロックが正常に終了した場合、どの順序で閉じられますか？",
          "options": [
            {
              "icon": "",
              "label": "Aが最初に閉じられ、その後B——宣言順序に一致"
            },
            {
              "icon": "",
              "label": "Bが最初に閉じられ、その後A——try-with-resourcesはリソースを宣言された順序の逆順で閉じる"
            },
            {
              "icon": "",
              "label": "両方同時に閉じられる——try-with-resourcesはクリーンアップを並列化"
            },
            {
              "icon": "",
              "label": "Bのみが自動的に閉じられる——Aは引き続きfinallyブロックで手動で閉じる必要があります"
            }
          ]
        },
        {
          "question": "int getValue() { try { return 1; } finally { return 2; } } getValue() を呼び出すと何を返しますか？",
          "options": [
            {
              "icon": "",
              "label": "1——try ブロックの戻り値は既に確定されてから finally が実行され、finally はそれを変えられない"
            },
            {
              "icon": "",
              "label": "実行時に例外をスロー——メソッドは2つの場所から返せない"
            },
            {
              "icon": "",
              "label": "2——finally 内の return 文は、try ブロックから既に進行中の戻り値をオーバーライドして置換え、値1を完全に破棄"
            },
            {
              "icon": "",
              "label": "コンパイルエラー——finally は return 文を含むことを許さない"
            }
          ]
        },
        {
          "question": "try { ... } catch (IOException e) { ... } catch (FileNotFoundException e) { ... }、FileNotFoundException はIOException を拡張します。これをコンパイルしようとするとどうなりますか？",
          "options": [
            {
              "icon": "",
              "label": "コンパイルエラー——FileNotFoundException catch ブロックは到達不可——より一般的なIOException catch ブロックは既にすべてのFileNotFoundException をマッチ"
            },
            {
              "icon": "",
              "label": "コンパイルは正常で、その正確な型がスロー時にFileNotFoundException ブロックが実行される"
            },
            {
              "icon": "",
              "label": "コンパイル正常で、FileNotFoundException に対して両方のcatchブロックが順番に実行"
            },
            {
              "icon": "",
              "label": "コンパイル時は正常ですが、実際にFileNotFoundException が発生すると最初に実行時エラーをスロー"
            }
          ]
        },
        {
          "question": "クラスはsynchronized インスタンスメソッドprocess() とsynchronized staticメソッドconfigure() を持ちます。各々は正確に何をロックしますか？",
          "options": [
            {
              "icon": "",
              "label": "process() は呼ばれる特定のオブジェクトインスタンスのモニターをロック、configure() はClassオブジェクト自身のモニターをロック——あらゆるインスタンスで共有"
            },
            {
              "icon": "",
              "label": "両方ともJVM全体の単一のグローバルロックをロック、インスタンスまたはクラスに関わらず"
            },
            {
              "icon": "",
              "label": "process() はClassオブジェクトをロック、configure() はそれを呼ぶインスタンスをロック"
            },
            {
              "icon": "",
              "label": "どちらもメソッド本体内でsynchronized ブロックも使用されない限り、実際にはロックしない"
            }
          ]
        },
        {
          "question": "フィールドはvolatile int counter = 0; と宣言され、複数のスレッドが並行してcounter++ を実行します。volatile は失われたアップデートを防ぎますか？",
          "options": [
            {
              "icon": "",
              "label": "はい——volatile はフィールド上のすべての操作をアトミック化し、インクリメント含む"
            },
            {
              "icon": "",
              "label": "いいえ——volatile はスレッド間で最新の書き込みが見える（見える性）のみを保証し、counter++ は複数のステップのread-modify-write で、volatile はアトミック性を何もしない"
            },
            {
              "icon": "",
              "label": "はい、ただしint とlong フィールドに限定——JVMが64ビット値を処理する方法"
            },
            {
              "icon": "",
              "label": "いいえ、そしてvolatile はintのようなプリミティブ型の見える性も保証できない"
            }
          ]
        },
        {
          "question": "InterfaceAとInterfaceB は両方ともdescribe() デフォルトメソッドを宣言します。クラスはAとBを両方実装し、describe() 自体をオーバーライドしません。何が起きますか？",
          "options": [
            {
              "icon": "",
              "label": "コンパイラはImplementsクローズでリストされているため、InterfaceAのバージョンを自動的に選択"
            },
            {
              "icon": "",
              "label": "両方のバージョンが実行される——describe() を呼ぶたびに1つの後に1つ"
            },
            {
              "icon": "",
              "label": "コンパイル時は正常ですが、初めてdescribe() が呼ばれるときAmbiguousMethodException をスロー"
            },
            {
              "icon": "",
              "label": "コンパイルエラー——2つのインターフェースが同じデフォルトメソッドを提供する場合、実装クラスは曖昧性を解決するためそれ自体をオーバーライドする必要があります。Javaはあなたがどちらを意図したかを推測しません"
            }
          ]
        },
        {
          "question": "list.stream().filter(x -> x > 0).map(x -> x * 2); はターミナル操作.collect() または.forEach() に割り当てられないまま書かれています。この行が実行されるときに実際に何が起きますか？",
          "options": [
            {
              "icon": "",
              "label": "リストの要素は何も起きない——filter とmap は遅延中間操作で、パイプラインの説明のみを構築。ターミナル操作なしでは、そのパイプラインはまったく実行されない"
            },
            {
              "icon": "",
              "label": "すべての要素がターミナル操作が呼ばれている場合と同じように、即座にフィルタリング、マップされる"
            },
            {
              "icon": "",
              "label": "filterのみが即座に実行される。map はターミナル操作が現れるまで遅延"
            },
            {
              "icon": "",
              "label": "IllegalStateException をスロー——ストリームパイプラインはコンパイルするためにターミナル操作を必須"
            }
          ]
        }
      ],
      "optionOrderVersion": "0154f9576054ad6f"
    }
  }
}