JEP530 : Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

Transcript

1. JEP530: Primitive Types in Patterns, instanceof, and switch (Fourth Preview) 2026/03/24 JJUGナイトセミナー 「Java 26 リリース記念イベント」
2. 自己紹介 2
3. JEP530の概要 「すべてのプリミティブ型を、 パターンマッチングで扱えるようにする」 以下の3つでプリミティブ型がフルサポートされる 1. instanceof演算子 2. switch文 / switch式 3. Record Pattern 3
4. プリミティブ型でパターンマッチング① int i = ...; if(i >= Byte.MIN_VALUE && <= Byte.MAX_VALUE){ byte b = (byte)i; ... 4 int i = ...; if(i instanceof byte b){ ... こう書けるように • instanceofでプリミティブ型が使える
5. プリミティブ型でパターンマッチング② 5 long id = ...; switch(id){ case 1L -> {} case 2L -> {} default -> {} } • 今までのswitchで使えたもの • int・char・byte・shortとそれらのラッパー, String, enum • 新しく使えるようになるもの • long, float, double, boolean
6. プリミティブ型でパターンマッチング③ 6 void process(Number n){ switch (n){ case int _ -> {} case double _ -> {} default -> {} } } • switchのcaseラベルでプリミティブ型が使える
7. プリミティブ型でパターンマッチング④ 7 record Point(int x, int y){} Object obj = ... //←ObjectとしてPointが渡された if(obj instanceof Point(byte x, byte y)){ ... // Pointの中身がbyteに収まる場合のみ処理 • レコードパターンと統合
8. リリースの歴史 JEP455 JDK23 Preview ↓ JEP488 JDK24 Second Preview ↓ JEP507 JDK25 Third Preview ↓ JEP530 JDK26 Fourth Preview 8
9. 今回の変更点 2つの変更点が提案 1. 無条件の正確性(unconditional exactness)の定義の強化 2. switch構文における、より厳密な支配(dominance)チェックの 適用 9
10. Dominance(支配)の原則 • 到達不可能なcaseを防ぐため、広範なパターンが先に来たら コンパイラはエラーを出さなければならない Object o = "test"; switch (o){ case Object _ -> {} case String _ -> {} default -> {} } 10
11. パターンの「支配」判定の複雑化 • 参照型の場合はシンプル： • ObjectはStringを支配する（親クラスは子クラスを完全に覆う） という明確なルールがあった • プリミティブの導入による混乱 • 「intはbyteを支配するのか？」「Integerはintを支配するのか？」 int x = …; switch (x){ case byte _ -> {} case int _ -> {} default -> {} }; xの値によって当てはまるcaseが変わる 11
12. Unconditional Exactness(無条件の正確性)とは？ 常に安全な変換かどうかの基準 • ある型Aから型Bへの変換が、実行時の具体的な値に依存せず、 常に情報損失なく(Exactlyに)行えること • byte → int：Unconditionally Exactである • どんなbyteの値も絶対にintに収まる • int → byte：Unconditionally Exactではない • 100なら収まるが、1000なら収まらないなど、値に依存する • int → float：Unconditionally Exactではない • 大きな桁のintは、floatにすると下位の精度が落ちる 12 例
13. JEP530での再定義 ある型Tが型Uを支配するのは、UからTへの変換が Unconditionally Exactである場合に限る • コンパイラが、数学的に矛盾なく「到達不能コード」を判定し、 適切なエラーを出すようになった 13 int j = …; switch (j){ case float f -> {} case 16_777_216 -> {} default -> {} };
14. 2種類のUnconditionally Exact • Type-based • 入力値にかかわらず、型の性質のみで安全性が保証される変換 14 int x = … switch (x){ case int _ -> {} case byte _ -> {} default -> {} }; byte→ int, int→long, float→double int→Integer, String→Object 例
15. 2種類のUnconditionally Exact • Value-based • 定数式限定 コンパイラが値そのものを解析して、情報欠落がないと判定されたもの 15 byte x = …; switch (x){ case 100 -> {} case 1000 -> {} default -> {} };
16. 互換性が失われたもの • 以前はOKだった • OKだと、開発者がBに到達可 能性があると誤解するかも • 今回からエラーになった 16 interface A {} interface B {} A a = …; switch (a){ case A -> {} case B -> {} };
17. まとめ • 統一感の向上 • プリミティブとオブジェクトの文法的な壁がなくなり、 一貫したコードが書ける • 安全性の向上 • オーバーフローや精度落ちをコンパイル時に安全にチェック 17