リテラル（整数リテラルの既定型と L サフィックス）難易度 標準無料
次のコードのコンパイル結果として正しいものを選べ。
1 public class Q13 {
2 public static void main(String[] args) {
3 long x = 3000000000;
4 System.out.println(x);
5 }
6 }
- Aコンパイルエラー（
Lサフィックスが無く、リテラルがintの範囲を超えている） - Bコンパイル成功・実行して
3000000000と出力される - Cコンパイル成功。ただし値はオーバーフローして負の値になる
- Dコンパイルエラー（
long型の変数は数値リテラルで初期化できない）
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・AIで再検証済
解説
整数リテラル（
各誤答が違う理由L サフィックスの無いもの）は既定で int 型として解釈される。これは代入先の変数の型（ここでは long）とは無関係で、リテラル自体が先に int として評価される。
int の表現範囲は約 -21億〜+21億（正確には -2147483648 〜 2147483647）。3000000000 はこの範囲を超えているため、
リテラルの時点で「too large」なリテラルとしてコンパイルエラーになる。long 型の変数へ代入しようとしていることは救済にならない。
正しく書くには long x = 3000000000L; のようにL サフィックスを付け、リテラル自体を long として扱わせる必要がある。
- B代入先が
longであってもリテラル自体は既定でintとして解釈される。intの範囲を超える値はサフィックスを付けない限りコンパイルエラーになる。 - Cオーバーフローが発生するのはコンパイルが通った後の実行時の話。本コードはリテラルの時点で
int範囲外と検出され、そもそもコンパイルが失敗する。 - D
Lサフィックスを付けたリテラル（例：3000000000L）であればlong変数の初期化に問題なく使える。エラーの原因はサフィックス無しでの範囲超過。
ひっかけ： 「代入先が
long だからリテラルも自動的に long として扱われる」という誤解が罠。リテラルの型はサフィックスだけで決まり、代入先の型は無関係。L（小文字の l は数字の1と紛らわしいため非推奨）を付け忘れると int の範囲チェックで弾かれる。コマンド例と想定される挙動（未実行）
javac でコンパイル：
Q13.java:3: error: integer number too large: 3000000000
long x = 3000000000;
^
→ コンパイル不成立（実行に至らない）。公式ドキュメント・関連JLS SE11 §3.10.1 Integer Literals↗
AIが作成し、別の手順のAIで誤りを点検した解説です（有資格者による監修は経ていません）