Java17以降で追加された構文の使いどころ

Javaはバージョン17以降、長年の保守的な進化から一転して、型安全・表現力強化に主眼を置いた構文拡張が相次いでいます。
ただし、それらを「便利な記法」としてのみ扱ってしまうと、設計判断やレビューにおいて見落としや誤解を招くリスクがあります。

本記事では、Java 17〜21で追加された構文群のうち、レビュー観点から注意すべき設計意図と使いどころを解説します。

Java17以降で注目すべき構文一覧

構文機能 初出バージョン 目的
sealed classes Java 17 継承の制限と型の網羅性
record patterns Java 19〜21 分解処理の簡素化
switch式の強化 Java 14〜21 パターンマッチングとの統合
text block Java 15 複数行文字列の簡潔記述
instanceofの強化 Java 16 型キャスト不要のパターンマッチ
注:この記事ではローカル変数型推論(var)などは対象外としています

設計判断やレビュー上の影響が相対的に小さいため、今回は除外します。

record patterns:データの分解を構文レベルで扱う

従来、Javaではデータの分解が煩雑でした。

旧来の手法
if (obj instanceof Person) {
  Person p = (Person) obj;
  String name = p.name();
  int age = p.age();
}

Java 19以降では、recordパターンによって構文的に分解が可能になります。

record patternの例
if (obj instanceof Person(String name, int age)) {
  // name と age が直接使える
}

この構文により、条件分岐とデータ取り出しの責務が統合される設計が可能になります。

レビュー観点:構造と条件の混在

record patternは条件分岐の中で構造を直接扱うため、処理が密結合になっていないかをレビュー時に確認しましょう。

switch式とパターンマッチングの統合

Java 14以降の switch 構文は、従来の値一致ベースからパターン一致ベースの式的構文へと進化しています。

型に応じたswitch構文
static String formatShape(Shape s) {
  return switch (s) {
    case Circle c -> "円";
    case Rectangle r -> "長方形";
  };
}
  • return が switch の外ではなく中にある
  • 型ガード(instanceofに相当)を switch 文内で完結できる

これにより型の分岐を関数的に記述できる設計が可能になります。

冗長な型分岐に注意

分岐の条件が switch で濫用されている場合、sealedやenumによる設計で代替できる可能性があります。

instanceof + パターンマッチング:型の明示と同時に変数束縛

if (s instanceof Circle c) {
  double r = c.radius();
}

これにより、型チェックとキャストの分離という冗長が解消されました。
ただし、レビュー時には「この変数束縛が本当に安全か?副作用がないか?」を見抜く必要があります。

Comment
@Reviewer: `instanceof Circle c` などで変数を束縛したあと、副作用を持つ操作が続いていないか確認してください。

text block:文字列定数の視認性向上

Java 15で導入された text block は、HTMLやJSONなどの長文定数の可読性を高めます。

String html = """
  <html>
    <body>Hello</body>
  </html>
""";

レビュー時には、

  • 表示構造が意味的に破綻していないか
  • 改行やスペースが実行結果に影響する構造になっていないか

を確認するとよいでしょう。

HTMLテンプレートの組み込みなどでは意外に影響が大きい

ビューエンジンやテンプレート処理と組み合わせる際、text block の空白・改行が意図せぬ描画崩れを起こすことがあります。

レビュー観点のチェックリスト:新構文への適用判断

以下の観点から、構文の使い所が設計意図と一致しているかをレビューします。

Comment
@Reviewer: 新構文の導入が“設計を明確にするための選択”であるか、それとも“書きやすさ優先の短絡”になっていないかを見極めましょう。

まとめ:構文拡張は「設計の表現手段」である

Java17以降の構文は、確かに開発をスムーズにします。
しかし、レビューアーの立場から重要なのは、それら構文が「設計判断を明快にするために使われているか」どうかです。

  • 書きやすいから使う、ではなく
  • 設計が読みやすくなるか、明快になるか

という観点から、新構文の選定と適用をレビューすべきです。