JEP 433：开关的模式匹配（第四次预览）

Google Translate

概括

switch通过表达式和语句的模式匹配增强 Java 编程语言。扩展模式匹配允许switch针对多个模式测试表达式，每个模式都有一个特定的操作，以便可以简洁、安全地表达复杂的面向数据的查询。这是预览语言功能。

历史

模式匹配由JEP 406switch提议作为预览功能并在JDK 17中提供，由 JEP 420提议作为第二个预览并在JDK 18中提供，由 JEP 427提议作为第三个预览并在JDK 19中提供。此 JEP 提出了第四个预览，以使其能够与记录模式预览功能 ( JEP 432 )持续共同进化，并允许基于持续的经验和反馈进行其他改进。

自第三次预览以来的主要变化是：

现在，类上的详尽开关（即switch表达式或模式switch语句）会抛出异常，而不是在运行时没有应用开关标签时抛出异常。enum``MatchException``IncompatibleClassChangeError
开关标签的语法更简单。
switch现在，表达式和语句以及支持模式的其他构造支持通用记录模式的类型参数推断。

目标

switch通过允许模式出现在case标签中来扩展表达式和语句的表现力和适用性。
switch在需要时允许放松历史上的零敌意。
switch通过要求模式switch语句涵盖所有可能的输入值来提高语句的安全性。
确保所有现有switch表达式和语句继续编译而不进行任何更改并以相同的语义执行。

动机

在 Java 16 中，JEP 394扩展了该instanceof运算符以采用_类型模式_并执行_模式匹配_。这种适度的扩展允许简化熟悉的 instanceof-and-cast 习惯用法，使其更加简洁且不易出错：

// Old code
if (obj instanceof String) {
    String s = (String)obj;
    ... use s ...
}

// New code
if (obj instanceof String s) {
    ... use s ...
}

我们经常想要将一个变量与obj多个替代方案进行比较。 Java 支持switch语句和switch表达式（JEP 361 ）的多路比较，但不幸的switch是非常有限。您只能打开几种类型的值 - 整型原始类型（不包括long）、其相应的装箱形式、enum类型和String- 并且只能测试与常量的精确相等。我们可能想使用模式来针对多种可能性测试同一变量，对每种可能性采取特定的操作，但由于现有的switch不支持，我们最终会得到一系列if...else测试，例如：

static String formatter(Object obj) {
    String formatted = "unknown";
    if (obj instanceof Integer i) {
        formatted = String.format("int %d", i);
    } else if (obj instanceof Long l) {
        formatted = String.format("long %d", l);
    } else if (obj instanceof Double d) {
        formatted = String.format("double %f", d);
    } else if (obj instanceof String s) {
        formatted = String.format("String %s", s);
    }
    return formatted;
}

该代码受益于使用模式instanceof表达式，但它远非完美。首先也是最重要的，这种方法可以隐藏编码错误，因为我们使用了过于通用的控制结构。目的是为链formatted的每个分支分配一些内容if...else，但没有任何东西可以使编译器识别和验证此不变量。如果某个块（也许是很少执行的块）没有分配给formatted，我们就会遇到一个错误。（声明formatted为空白本地至少会在这项工作中利用编译器的明确赋值分析，但开发人员并不总是编写这样的声明。）此外，上述代码不可优化；如果没有编译器英雄，它将具有_O_ ( n ) 时间复杂度，即使底层问题通常是_O_ (1)。

但switch对于图案搭配来说却是绝配！如果我们扩展switch语句和表达式以适用于任何类型，并允许使用case模式标签而不仅仅是常量，那么我们可以更清晰可靠地重写上面的代码：

static String formatterPatternSwitch(Object obj) {
    return switch (obj) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> obj.toString();
    };
}

其语义switch很明确：case如果选择器表达式的值与obj模式匹配，则应用带有模式的标签。（为了简洁起见，我们显示了一个switch表达式，但也可以显示一个switch语句；switch 块（包括case标签）将保持不变。）

这段代码的意图更加清晰，因为我们使用了正确的控制结构：我们是说，“参数obj最多匹配以下条件之一，找出并评估相应的手臂。”作为奖励，它更加可优化；在这种情况下，我们更有可能能够在_O_ (1) 时间内执行调度。

开关和空值

传统上，如果选择器表达式的计算结果为，则switch语句和表达式会抛出异常，因此必须在之外进行测试：NullPointerException``null``null``switch

static void testFooBar(String s) {
    if (s == null) {
        System.out.println("Oops!");
        return;
    }
    switch (s) {
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}

switch当仅支持少数引用类型时，这是合理的。然而，如果switch允许任何类型的选择器表达式，并且case标签可以具有类型模式，那么独立null测试感觉像是任意的区别，并且会带来不必要的样板文件和出错的机会。最好通过允许新的案例标签将null测试集成到中：switch``null

static void testFooBar(String s) {
    switch (s) {
        case null         -> System.out.println("Oops");
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}

switch当选择器表达式的值为时，其行为null始终由其标签决定case。使用 a case null，switch执行与该标签关联的代码；如果没有 a case null，则switch抛出NullPointerException，就像以前一样。（为了保持与当前语义的向后兼容性switch，default标签与选择器不匹配null。）

对模式的实验switch表明，希望改进模式标签所体现的测试是很常见的。例如，考虑以下切换值的代码Shape：

class Shape {}
class Rectangle extends Shape {}
class Triangle  extends Shape { int calculateArea() { ... } }

static void testTriangle(Shape s) {
    switch (s) {
        case null:
            break;
        case Triangle t:
            if (t.calculateArea() > 100) {
                System.out.println("Large triangle");
                break;
            }
        default:
            System.out.println("A shape, possibly a small triangle");
    }
}

此代码的目的是为大三角形（面积超过 100 的三角形）提供特殊情况，为其他所有三角形（包括小三角形）提供默认情况。然而，我们不能用单一模式直接表达这一点。我们首先必须编写一个case匹配所有三角形的标签，然后将三角形面积的测试相当不舒服地放在相应的语句组中。然后，当三角形的面积小于 100 时，我们必须使用 drop-through 来获得正确的行为。（请注意语句break在if块内的小心放置。）

这里的问题是，使用单一模式来区分情况并不能超出单一条件——我们需要某种方法来表达对模式的细化。因此，我们允许whenswitch 块中的子句指定模式case标签的保护，例如case Triangle t when t.calculateArea() > 100。我们将这样的case标签称为_受保护_ case标签，并将布尔表达式称为_守卫_。

通过这种方法，我们可以重新访问testTriangle代码来直接表达大三角形的特殊情况。这消除了在语句中使用 drop-through 的情况switch，这又意味着我们可以享受简洁的箭头式 ( ->) 规则：

static void testTriangle(Shape s) {
    switch (s) {
        case null -> 
            { break; }
        case Triangle t
        when t.calculateArea() > 100 ->
            System.out.println("Large triangle");
        default ->
            System.out.println("A shape, possibly a small triangle");
    }
}

如果的值与s模式匹配Triangle t并且随后防护t.calculateArea() > 100评估为true，则采用第二个子句。（守卫能够使用case标签中模式声明的任何模式变量。）

当应用程序需求发生变化时，使用switch它可以轻松理解和更改案例标签。例如，我们可能想从默认路径中分割出三角形；我们可以通过使用两个 case 子句来做到这一点，一个带有保护，另一个不带：

static void testTriangle(Shape s) {
    switch (s) {
        case null -> 
            { break; }
        case Triangle t
        when t.calculateArea() > 100 ->
            System.out.println("Large triangle");
        case Triangle t ->
            System.out.println("Small triangle");
        default ->
            System.out.println("Non-triangle");
    }
}

描述

我们switch通过三种方式增强陈述和表达：

扩展case标签以包含模式和null常量，
switch扩大语句和表达式的选择器表达式允许的类型范围switch，以及
允许可选when子句跟随case标签。

为了方便起见，我们还引入了_括号模式_。

开关标签中的模式

我们修改 switch 块中 switch 标签的语法来读取（比较JLS §14.11.1）：

SwitchLabel:
  case CaseConstant { , CaseConstant }
  case null [, default]
  case Pattern
  default

主要增强功能是引入一个新case标签，case p其中p是模式。本质switch没有改变：将选择器表达式的值与开关标签进行比较，选择标签之一，并执行或评估与该标签关联的代码。现在的区别在于，对于case带有模式的标签，选择的标签是由模式匹配的结果决定的，而不是由相等性测试决定的。例如，在以下代码中，的值与obj模式匹配，并且计算Long l与标签关联的表达式：case Long l

Object obj = 123L;
String formatted = switch (obj) {
    case Integer i -> String.format("int %d", i);
    case Long l    -> String.format("long %d", l);
    case Double d  -> String.format("double %f", d);
    case String s  -> String.format("String %s", s);
    default        -> obj.toString();
};

成功的模式匹配后，我们通常会进一步测试匹配的结果。这可能会导致代码变得繁琐，例如：

static void test(Object obj) {
    switch (obj) {
        case String s:
            if (s.length() == 1) { ... }
            else { ... }
            break;
        ...
    }
}

不幸的是，所需的测试（即长度为 1 的obja String）被分割在模式case标签和以下if语句之间。

为了解决这个问题，我们通过在模式标签后支持可选的保护来引入_保护模式case标签_。这允许重写上面的代码，以便将所有条件逻辑提升到 switch 标签中：

static void test(Object obj) {
    switch (obj) {
        case String s when s.length() == 1 -> ...
        case String s                      -> ...
        ...
    }
}

第一个子句匹配 if objis aString _且_长度为 1。第二个子句匹配 if objis aString任意长度。

只有图案标签才能有防护。例如，写一个带有常量case和保护的标签是无效的；例如，case "Hello" when RandomBooleanExpression()。

有时我们需要将模式括起来以提高可读性。因此，我们扩展了模式语言以支持编写_的括号模式_(p)，其中p是模式。带括号的模式(p)引入了由子模式引入的模式变量p。(p)如果值与模式匹配，则该值与带括号的模式匹配p。

支持以下模式时需要考虑五个主要的语言设计领域switch：

增强类型检查
switch表达式和陈述的详尽性
模式变量声明的范围
处理null
错误

1. 增强类型检查

1a.选择器表达式输入

支持 in 模式switch意味着我们可以放宽当前对选择器表达式类型的限制。目前，法线的选择器表达式的类型switch必须是整型原始类型（不包括long）、相应的装箱形式（即、Character、Byte或Short）Integer、String或enum类型。我们对此进行了扩展，并要求选择器表达式的类型是整型原始类型（不包括long）或任何引用类型。

例如，在以下模式中，switch选择器表达式与涉及类类型、类型、记录类型和数组类型以及标签和 a 的obj类型模式匹配：enum``null case``default

record Point(int i, int j) {}
enum Color { RED, GREEN, BLUE; }

static void typeTester(Object obj) {
    switch (obj) {
        case null     -> System.out.println("null");
        case String s -> System.out.println("String");
        case Color c  -> System.out.println("Color: " + c.toString());
        case Point p  -> System.out.println("Record class: " + p.toString());
        case int[] ia -> System.out.println("Array of ints of length" + ia.length);
        default       -> System.out.println("Something else");
    }
}

switch 块中的每个case标签都必须与选择器表达式兼容。对于case带有模式的标签（称为_模式标签），我们使用__表达式与模式的兼容性_的现有概念（JLS §14.30.1）。

1b.`case`标签的主导地位

支持模式case标签意味着对于选择器表达式的给定值，现在可以应用多个case标签（以前最多只能case应用一个标签）。例如，如果选择器表达式的计算结果为 a，String则case标签case String s和case CharSequence cs都将适用。

要解决的第一个问题是准确决定在这种情况下应应用哪个标签。我们没有尝试复杂的最佳拟合方法，而是采用更简单的语义：case选择出现在 switch 块中的第一个适用于某个值的标签。

static void first(Object obj) {
    switch (obj) {
        case String s ->
            System.out.println("A string: " + s);
        case CharSequence cs ->
            System.out.println("A sequence of length " + cs.length());
        default -> {
            break;
        }
    }
}

在此示例中，如果的值obj是类型，则将应用String第一个标签；case如果它是类型CharSequence但不是类型String，则将应用第二个模式标签。

case但是如果我们交换这两个标签的顺序会发生什么？

static void error(Object obj) {
    switch (obj) {
        case CharSequence cs ->
            System.out.println("A sequence of length " + cs.length());
        case String s ->    // Error - pattern is dominated by previous pattern
            System.out.println("A string: " + s);
        default -> {
            break;
        }
    }
}

现在，如果的值obj属于类型，则应用String标签CharSequence case，因为它首先出现在 switch 块中。该String case标签是不可访问的，因为选择器表达式没有值会导致它被选择。与无法访问的代码类似，这被视为程序员错误并导致编译时错误。

更准确地说，我们说第一个case标签case CharSequence cs _支配_第二个case标签，case String s因为与模式匹配的每个值String s也与模式匹配CharSequence cs，但反之则不然。这是因为第二个模式的类型String是第一个模式的类型的子类型CharSequence。

未受保护的模式标签支配具有相同模式的case受保护的模式标签。case例如，（不受保护的）模式case标签case String s支配受保护模式case标签，因为与标签case String s when s.length() > 0匹配的每个值都必须与标签匹配。case``case String s when s.length() > 0``case``case String s

仅当前者的模式支配后者的模式_并且_其保护是 value 的常量表达式时，受保护的模式case标签才支配另一个模式标签（受保护或不受保护）。例如，受保护的模式标签支配模式标签。我们不再进一步分析保护表达式，以便更精确地确定哪些值与模式标签匹配（这个问题通常是无法判定的）。case``true``case``case String s when true``case``case String s

模式case标签可以支配常量case标签。例如，模式case标签case Integer i支配常量case标签，当是类 type的成员时case 42，模式case标签case E e支配常量case标签。如果没有保护的相同模式标签支配常量标签，则受保护模式标签支配常量标签。换句话说，我们不检查守卫，因为这通常是不可判定的。例如，正如预期的那样，模式标签支配着常量标签；但霸占了标签。case A``A``enum``E``case``case``case``case``case String s when s.length() > 1``case``case "hello"``case Integer i when i != 0``case``case 0

所有这些都表明了一种简单、可预测且可读的case标签顺序，其中常量case标签应出现在受保护的模式case标签之前，而这些标签应出现在不受保护的模式case标签之前：

Integer i = ...
switch (i) {
    case -1, 1 -> ...                 // Special cases
    case Integer i when i > 0 -> ...  // Positive integer cases
    case Integer i -> ...             // All the remaining integers
}

编译器检查所有case标签。case如果 switch 块中的标签被case该 switch 块中的前一个标签所支配，则这是一个编译时错误。此主导要求确保如果开关块仅包含类型模式case标签，它们将按子类型顺序出现。

（支配的概念类似于catch语句子句的条件，如果捕获异常类的子句前面有一个可以捕获异常类的子句或( JLS §11.2.3 )的超类，try则这是一个错误。逻辑上，前面的子句支配后面的子句。）catch``E``catch``E``E``catch``catch

switch如果表达式或switch语句的 switch 块具有多个全匹配 switch 标签，这也是一种编译时错误。全部匹配标签是default模式case标签，其中模式无条件匹配选择器表达式。例如，类型模式String s无条件匹配 type 的选择器表达式String，而类型模式Object o无条件匹配任何引用类型的选择器表达式。

1c.记录模式中类型参数的推断

如果记录模式命名通用记录类但未给出类型参数（即记录模式使用原始类型），则始终会推断类型参数。例如：

record MyPair<S,T>(S fst, T snd){};

static void recordInference(MyPair<String, Integer> pair){
    switch (pair) {
        case MyPair(var f, var s) -> 
            ... // Inferred record Pattern MyPair<String,Integer>(var f, var s)
        ...
    }
}

所有支持模式的构造都支持记录模式的类型参数推断：switch语句和表达式、instanceof表达式和增强for语句。

2.`switch`表述和陈述的详尽性

表达式switch要求选择器表达式的所有可能值都在 switch 块中处理；换句话说，它必须是_详尽无遗的_。这保持了switch表达式的成功求值总是会产生一个值的属性。对于普通switch表达式，这是通过 switch 块上一组相当简单的额外条件来强制执行的。

对于模式表达式和语句，我们通过在 switch 块中定义 switch 标签的_类型覆盖_switch概念来实现这一点。然后组合 switch 块中所有 switch 标签的类型覆盖率，以确定 switch 块是否耗尽了选择器表达式的所有可能性。

考虑这个（错误的）模式switch表达式：

static int coverage(Object obj) {
    return switch (obj) {         // Error - not exhaustive
        case String s -> s.length();
    };
}

开关块只有一个开关标签case String s。这匹配obj其类型是的子类型的任何值String。因此，我们说这个开关标签的类型覆盖范围是的每个子类型String。该模式switch表达式并不详尽，因为其 switch 块（的所有子类型）的类型覆盖范围String不包括选择器表达式 ( Object) 的类型。

考虑这个（仍然是错误的）例子：

static int coverage(Object obj) {
    return switch (obj) {         // Error - still not exhaustive
        case String s  -> s.length();
        case Integer i -> i;
    };
}

该开关块的类型覆盖范围是其两个开关标签的覆盖范围的并集。换句话说，类型覆盖率是的所有子类型的集合String和的所有子类型的集合Integer。但是，类型覆盖仍然不包括选择器表达式的类型，因此该模式switch表达式也不详尽，并会导致编译时错误。

标签的类型覆盖范围default是所有类型，因此这个示例（终于！）合法：

static int coverage(Object obj) {
    return switch (obj) {
        case String s  -> s.length();
        case Integer i -> i;
        default -> 0;
    };
}

如果选择器表达式的类型是密封类（JEP 409），则类型覆盖检查可以考虑permits密封类的子句来确定 switch 块是否是详尽的。这有时可以消除对子句的需要default。考虑以下接口示例，该sealed接口S具有三个允许的子类A、B和C：

sealed interface S permits A, B, C {}
final class A implements S {}
final class B implements S {}
record C(int i) implements S {}  // Implicitly final

static int testSealedExhaustive(S s) {
    return switch (s) {
        case A a -> 1;
        case B b -> 2;
        case C c -> 3;
    };
}

编译器可以确定 switch 块的类型覆盖是类型A, B, 和C。由于选择器表达式的类型S是一个密封接口，其允许的子类正是A、B和C，因此该开关块是详尽的。因此，不需要default标签。

当允许的直接子类仅实现（通用）超类的特定参数化时，需要额外小心sealed。例如：

sealed interface I<T> permits A, B {}
final class A<X> implements I<String> {}
final class B<Y> implements I<Y> {}

static int testGenericSealedExhaustive(I<Integer> i) {
    return switch (i) {
        // Exhaustive as no A case possible!
        case B<Integer> bi -> 42;
    }
}

唯一允许的子类I是A和B，但编译器可以检测到 switch 块只需要覆盖该类B即可穷举，因为选择器表达式的类型为I<Integer>。

这种详尽的条件适用于模式switch表达式和模式switch 语句。为了确保向后兼容性，所有现有switch语句将按原样进行编译。但是，如果switch语句使用此 JEP 中描述的任何switch增强功能，那么编译器将检查它是否详尽。（Java 语言的未来编译器可能会针对switch不详尽的遗留语句发出警告。）

switch更准确地说，任何使用模式或null标签或其选择器表达式不是旧类型（char、byte、short、int、Character、Byte、、Short、Integer、String或enum类型）之一的语句都需要详尽。例如：

sealed interface S permits A, B, C {}
final class A implements S {}
final class B implements S {}
record C(int i) implements S {}  // Implicitly final

static void switchStatementExhaustive(S s) {
    switch (s) {    // Error - not exhaustive;
                    // missing clause for permitted class B!
        case A a :
            System.out.println("A");
            break;
        case C c :
            System.out.println("C");
            break;
    };
}

default使大多数开关变得详尽只需在开关块末尾添加一个简单的子句即可。这使得代码更清晰、更容易验证。例如，以下模式switch语句并不详尽并且是错误的：

Object obj = ...
switch (obj) {    // Error - not exhaustive!
    case String s:
        System.out.println(s);
        break;
    case Integer i:
        System.out.println("Integer");
        break;
}

它可以变得详尽无遗：

Object obj = ...
switch (obj) {
    case String s:
        System.out.println(s);
        break;
    case Integer i:
        System.out.println("Integer");
        break;
    default:    // Now exhaustive!
        break;
}

记录模式（JEP 432 ）使详尽性的概念变得更加复杂，因为这些模式支持在其中嵌套其他模式。因此，详尽性的概念必须反映这种潜在的递归结构。

3. 模式变量声明的范围

模式变量（JEP 394）是由模式声明的局部变量。模式变量声明的不同寻常之处在于它们的作用域是_流敏感的_。回顾一下以下示例，其中类型模式String s声明了模式变量s：

static void test(Object obj) {
    if ((obj instanceof String s) && s.length() > 3) {
        System.out.println(s);
    } else {
        System.out.println("Not a string");
    }
}

的声明s位于表达式右侧操作数&&以及“then”块的范围内。但是，它不在“else”块的范围内：为了将控制转移到“else”块，模式匹配必须失败，在这种情况下，模式变量将不会被初始化。

我们扩展了模式变量声明的这种流敏感的范围概念，以包含使用case三个新规则的标签中出现的模式声明：

出现在 switch 标签中的模式变量声明的范围包括when该标签的任何子句。
case规则标签中出现的模式变量声明的范围包括出现在箭头右侧的switch表达式、块或语句。throw
case出现在带标签语句组的标签中的模式变量声明的范围switch包括该语句组的块语句。case禁止跌倒声明模式变量的标签。

此示例显示了第一条正在运行的规则：

static void test(Object obj) {
    switch (obj) {
        case Character c
        when c.charValue() == 7:
            System.out.println("Ding!");
            break;
        default:
            break;
        }
    }
}

模式变量的声明范围c包括when开关标签的表达式。

此变体显示了第二条规则的作用：

static void test(Object obj) {
    switch (obj) {
        case Character c -> {
            if (c.charValue() == 7) {
                System.out.println("Ding!");
            }
            System.out.println("Character");
        }
        case Integer i ->
            throw new IllegalStateException("Invalid Integer argument: "
                                            + i.intValue());
        default -> {
            break;
        }
    }
}

这里模式变量声明的范围c是第一个箭头右侧的块。模式变量声明的范围i是throw第二个箭头右侧的语句。

第三条规则比较复杂。让我们首先考虑一个示例，其中带标签的语句组只有一个case标签switch：

static void test(Object obj) {
    switch (obj) {
        case Character c:
            if (c.charValue() == 7) {
                System.out.print("Ding ");
            }
            if (c.charValue() == 9) {
                System.out.print("Tab ");
            }
            System.out.println("Character");
        default:
            System.out.println();
    }
}

模式变量的声明范围c包括语句组的所有语句，即两条if语句和一条println语句。该范围不包括该default语句组的语句，尽管第一个语句组的执行可以通过defaultswitch 标签并执行这些语句。

case我们禁止掉入声明模式变量的标签的可能性。考虑这个错误的例子：

static void test(Object obj) {
    switch (obj) {
        case Character c:
            if (c.charValue() == 7) {
                System.out.print("Ding ");
            }
            if (c.charValue() == 9) {
                System.out.print("Tab ");
            }
            System.out.println("character");
        case Integer i:                 // Compile-time error
            System.out.println("An integer " + i);
        default:
            break;
    }
}

obj如果允许这样做，并且 switch 块的then执行的值Character可能会落入第二个语句组（after case Integer i:），其中模式变量i不会被初始化。因此，允许执行通过case声明模式变量的标签是一个编译时错误。

case Character c: case Integer i: ...这就是为什么不允许使用由多个模式标签组成的开关标签，例如。类似的推理也适用于禁止在单个case标签内使用多种模式：既不case Character c, Integer i: ...也case Character c, Integer i -> ...不允许。如果case允许这样的标签，则c和i都将在冒号或箭头之后的范围内，但根据的值是objaCharacter还是 an ，只有其中一个会被初始化Integer。

另一方面，穿过未声明模式变量的标签是安全的，如以下示例所示：

void test(Object obj) {
    switch (obj) {
        case String s:
            System.out.println("A string");
        default:
            System.out.println("Done");
    }
}

4. 处理`null`

传统上，如果选择器表达式的计算结果为，则switch抛出a 。这是众所周知的行为，我们不建议对任何现有代码进行更改。NullPointerException``null``switch

然而，鉴于模式匹配和null值存在合理且无异常的语义，我们有机会使模式switch更加null友好，同时保持与现有switch语义的兼容。

首先，我们介绍一个新null case标签。然后，我们解除一揽子规则，如果选择器表达式的值为，则aswitch立即抛出。相反，我们检查标签来确定 a 的行为：NullPointerException``null``case``switch

如果选择器表达式的计算结果为，null则任何nullcase 标签都被认为是匹配的。如果没有与 switch 块关联的此类标签，则像以前一样switch抛出。NullPointerException
如果选择器表达式的计算结果为非值，null那么我们case照常选择一个匹配的标签。如果没有case标签匹配，则任何default标签都被视为匹配。

例如，给出下面的声明，评估test(null)将打印null!而不是抛出NullPointerException：

static void test(Object obj) {
    switch (obj) {
        case null     -> System.out.println("null!");
        case String s -> System.out.println("String");
        default       -> System.out.println("Something else");
    }
}

这种新行为就好像编译器自动用其主体抛出null异常来丰富 switch 块。换句话说，这段代码：case null``NullPointerException

static void test(Object obj) {
    switch (obj) {
        case String s  -> System.out.println("String: " + s);
        case Integer i -> System.out.println("Integer");
        default        -> System.out.println("default");
    }
}

相当于：

static void test(Object obj) {
    switch (obj) {
        case null      -> throw new NullPointerException();
        case String s  -> System.out.println("String: "+s);
        case Integer i -> System.out.println("Integer");
        default        -> System.out.println("default");
    }
}

在这两个示例中，评估test(null)都会导致NullPointerException抛出。

我们保留了现有结构的直觉switch，即执行切换null是一件特殊的事情。模式的区别switch在于，您有一种机制可以在内部switch而不是外部直接处理这种情况。如果您null在开关块中看到标签，则该标签将匹配一个null值。如果您在 switch 块中没有看到null标签，那么切换null值将像以前一样抛出NullPointerException。

想要将nullcase 与结合起来也是有意义的，而且并不罕见default。为此，我们允许null案例标签具有可选的default;例如：

Object obj = ...
switch (obj) {
    ...
    case null, default ->
        System.out.println("The rest (including null)");
}

obj如果的值是空参考值，或者其他标签都不匹配，则该值与该标签匹配case。

null case如果 switch 块同时具有带有 a 的标签default和 adefault标签，则会出现编译时错误。

5. 错误

模式匹配可能会突然完成。例如，当将值与记录模式匹配时，记录的访问器方法可能会突然完成。在这种情况下，模式匹配被定义为通过抛出MatchException.如果这样的模式作为 a 中的标签出现，switch那么switch也会通过抛出 a 来突然完成MatchException。

如果模式由表达式保护when，并且对when表达式求值突然完成，则switch出于同样的原因，也会突然完成。

如果模式中没有标签switch与选择器表达式的值匹配，则switch通过抛出 a 突然完成MatchException，因为模式切换必须是详尽的。

例如：

record R(int i){
    public int i(){      // accessor method for i
        return i / 0;
    }
}

static void exampleAnR(R r) {
    switch(r) {
        case R(var i): System.out.println(i);
    }
}

该调用会导致抛出exampleAnR(new R(42))a 。MatchException

相比之下：

static void example(Object obj) {
    switch (obj) {
        case R r when (r.i / 0 == 1): System.out.println("It's an R!");
        default: break;
    }
}

调用会导致抛出example(new R(42))an 。ArithmeticException

为了与模式switch语义保持一致，类switch的表达式enum现在会抛出异常MatchException，而不是IncompatibleClassChangeError在运行时没有应用开关标签时抛出异常。这是对语言的一个小的不兼容的更改。

未来的工作

目前，模式switch不支持基本类型boolean、long、float和double。它们的效用似乎很小，但可以添加对它们的支持。
我们期望，将来，通用类将能够声明解构模式来指定它们如何匹配。这种解构模式可以与模式一起使用switch来生成非常简洁的代码。例如，如果我们有一个Expr包含子类型 for IntExpr（包含单个int）、AddExprand MulExpr（包含两个Exprs）和NegExpr（包含单个）的层次结构，我们可以一步Expr匹配并作用于特定子类型：Expr
```
int eval(Expr n) {
     return switch (n) {
         case IntExpr(int i) -> i;
         case NegExpr(Expr n) -> -eval(n);
         case AddExpr(Expr left, Expr right) -> eval(left) + eval(right);
         case MulExpr(Expr left, Expr right) -> eval(left) * eval(right);
         default -> throw new IllegalStateException();
     };
}
```
如果没有这样的模式匹配，像这样表达临时多态计算需要使用麻烦的访问者模式。模式匹配通常更加透明和直接。
添加 AND 和 OR 模式也可能很有用，以便为case具有模式的标签提供更多表现力。

备择方案

switch我们可以定义一个仅支持切换选择器表达式类型的_类型switch_，而不是支持模式。此功能更易于指定和实现，但表现力却相当低。
受保护的模式标签还有许多其他语法选项，例如p where e、p if e，甚至p &&& e。
受保护模式标签的替代方案是直接支持_受保护模式_作为特殊模式形式，例如p && e。在之前的预览中对此进行了实验，由此产生的布尔表达式的歧义导致我们更喜欢when模式切换中的子句。

依赖关系

该 JEP 基于instanceof( JEP 394 ) 的模式匹配以及switch表达式 ( JEP 361 ) 提供的增强功能。当记录模式预览功能 ( JEP 432 ) 最终确定时，最终的实现可能会使用动态常量 ( JEP 309 )。

概括​

历史​

目标​

动机​

开关和空值​

案例细化​

描述​

开关标签中的模式​

1. 增强类型检查​

1a.选择器表达式输入​

1b.case标签的主导地位​

1c.记录模式中类型参数的推断​

2.switch表述和陈述的详尽性​

3. 模式变量声明的范围​

4. 处理null​

5. 错误​

未来的工作​

备择方案​

依赖关系​

概括

历史

目标

动机