歴史
スイッチ構文は、Cスタイルの制御フロー文から、Java 14の値を生成する完全な式へと進化しました。Java 17では、継承を制限するためにシールドクラスとインターフェースが導入され、スイッチのパターンマッチングがプレビュー機能として登場し、Java 21で標準化されました。この進化により、スイッチは単純なジャンプテーブルから、式として使用される際に完全性を保証しなければならない高度なパターンマッチングメカニズムに移行しました。
問題
スイッチが式として動作する場合（矢印構文 -> または yield を使用）、Javaの静的型システムを満たすために、すべての可能な入力に対して値を生成しなければなりません。従来のスイッチ文とは異なり、スイッチ式はすべての実行パスが値を返すことを絶対的に確実にする必要があります。シールド階層は許可されたすべてのサブタイプを明示的に列挙し、コンパイル時に完全なカバレッジが理論的に検証できる閉じた宇宙を作り出します。コンパイラは、この閉じた世界とオープンパターン（型パターンやnullケースなど）を調整し、未処理の型による実行時のMatchExceptionが発生しないことを確認しなければなりません。
解決策
コンパイラは、コンパイルのアトリビューションフェーズ中に優位性と完全性分析を実行します。シールドクラスの許可条項を有限の閉集合の型として扱います。スイッチ内の各パターンに対して、マッチした型を許可された型の宇宙から引き算します。最後のパターンの後に未マッチの許可されたサブタイプが残り、無条件の default や全体型パターンが存在しない場合、コンパイラはエラーでコードを拒否します。この分析は、特定のパターンが一般的なパターンの前に来なければならないというパターンの優位性ルールを尊重し、null入力を型パターンから別に処理するための合成機構を生成します。
sealed interface Payment permits Credit, Debit, Crypto {} record Credit() implements Payment {} record Debit() implements Payment {} record Crypto() implements Payment {} // Cryptoケースが欠けている場合はコンパイルエラー double fee = switch (payment) { case Credit c -> 0.02; case Debit d -> 0.01; // Cryptoケースが欠けていると "switch expression does not cover all possible values" };
問題の説明
決済処理マイクロサービスでは、楽器のタイプに基づいて料金を計算する必要がありました：Credit、Debit、BankTransfer、およびCrypto。ドメインモデルは、正確にこれら四つの実装を許可するシールドインターフェースPaymentInstrumentを使用していました。ジュニア開発者は、スイッチ式を使用して料金計算機を実装しましたが、Cryptoケースを誤って省略し、ゼロが暗黙的に返されると仮定していました。生産環境で暗号通貨の支払いが有効になったとき、この省略は実行時にMatchExceptionを引き起こし、トランザクションパイプラインをクラッシュさせ、緊急のロールバックを必要としました。
考慮された異なる解決策
解決策A: デフォルトケースのフォールバック
未処理の楽器を処理するために default -> 0.0 条項を追加することができます。このアプローチは、クラッシュを防ぐことによる即時の安全性を提供します。しかし、処理されていない型を静かに吸収することによってビジネスの意図を不明瞭にします。将来的に新しい楽器タイプがシールド階層に追加された場合、デフォルト条項は料金計算から隠され、収益の漏洩やコンプライアンス違反が発生する可能性があります。
解決策B: Enumベースの型マッピング
列挙型InstrumentTypeに移行すると、定数列挙によるコンパイル時の完全性チェックが可能になります。しかし、これは並行の分類を作成し、各支払い楽器が冗長な型メタデータを公開することを要求します。これは、各サブタイプがカード番号やブロックチェーンアドレスなどのユニークなデータフィールドを持つシールドクラスの多態的な豊かさを犠牲にし、不自然なデータの非正規化を強制します。
解決策C: コンパイラによって強制される完全なパターン シールド階層分析を利用して、許可された4つの型すべてについて明示的なケースを持つスイッチ式を実装します。このアプローチは、欠落したケースをコンパイルエラーとして扱い、シールドの許可が変更されるたびにコードベースの更新を強制します。ビルドフェーズに検証を左にシフトすることで、実行時のサプライズを排除します。
選択した解決策と結果
私たちは解決策Cを選び、コンパイラの警告を致命的なエラーとして扱うようにビルドパイプラインを設定しました。その後、製品チームがBuyNowPayLaterを五番目の許可されたサブタイプとして追加すると、CI/CDパイプラインは料金計算が不完全な17カ所を即座にフラグしました。これにより、展開前に税務、コンプライアンス、会計モジュール全体の調整された更新を強制し、新しい楽器が適切な財務論理を受け取ることを確保しました。コンパイル時の保証により、サイレントデフォルトを防ぎ、分散チーム内での型安全を維持しました。
null処理はパターンスイッチにおける完全性チェックとどのように相互作用するか？
多くの候補者は、シールドクラスのすべてのサブタイプをカバーすれば完全性要件が満たされると誤解しています。しかし、スイッチ式は、nullセレクタを型パターンとは異なるものとして扱います。別個の case null 条項または全体パターンが必須です。明示的なnull処理がない場合、コンパイラはNullPointerExceptionをスローする合成nullチェックを生成し、式は型に対しては技術的には完全でも、null値自体についてはそうではありません。
シールド階層に対するスイッチにデフォルト条項を追加すると、なぜシールド型の原則に潜在的に違反するのか？
候補者はしばしば防御的なコーディング習慣としてdefaultを追加しますが、これはシールドクラスの閉じた世界の仮定を損なうことを認識していません。デフォルト条項は、将来のリリースで許可リストに追加された型を含む、任意の型にマッチします。これにより、コンパイル時の完全性検証が実行時のキャッチオールに変わり、未処理の新しい型が静かに意図しないロジックを実行するという、シールドクラスが排除するために設計された脆弱性が再導入されます。
シールド型に対するスイッチ式が、現在のモジュールに見えないが許可された型に遭遇した場合はどうなるか？ このシナリオは、シールドクラスが別のパッケージまたはモジュールでパッケージプライベートなサブタイプを許可し、そのモジュールが現在のコンパイルユニットにエクスポートされない場合の可視性境界を含みます。コンパイラは、使用される場所で許可された型の完全なセットが不明なため、完全性を検証できず、ローカルで見えるすべての型が処理されているにもかかわらずコンパイルエラーが発生します。これを解決するには、デフォルト条項を追加する必要があります（完全性が損なわれます）またはJPMSモジュールエクスポートを調整して許可された型を見えるようにする必要があります。この問題は、モジュールの可アクセス性とパターンマッチングとの相互作用を強調します。