JEP 427：switch 模式匹配（第三次预览）
概述
增强 Java 编程语言，为 switch 表达式和语句添加模式匹配功能。将模式匹配扩展到 switch 可以使一个表达式根据多个模式进行测试，每个模式都有特定的操作，从而能够简洁且安全地表达以数据为导向的复杂查询。这是一个 预览语言功能。
历史
自第二次预览以来的主要变化包括：
-
带保护的模式被替换为
when子句在 switch 块中。 -
当选择器表达式的值为
null时，模式 switch 的运行时语义与传统的 switch 语义更加一致。
目标
-
通过允许在
case标签中出现模式，扩展switch表达式和语句的表现力与适用性。 -
在需要时，允许放宽
switch历史上对空值的严格限制。 -
通过要求模式
switch语句覆盖所有可能的输入值，提高switch语句的安全性。 -
确保所有现有的
switch表达式和语句继续编译且无需更改，并以相同的语义执行。
动机
在 Java 16 中，JEP 394 对 instanceof 运算符进行了扩展，使其能够接受一个类型模式并执行模式匹配。这一适度的扩展简化了常见的 instanceof-然后-转换的习惯用法：
// Old code
if (o instanceof String) {
String s = (String)o;
... use s ...
}
// New code
if (o instanceof String s) {
... use s ...
}
我们经常需要将一个变量（例如 o）与多个选项进行比较。Java 通过 switch 语句支持多路比较，并且从 Java 14 开始支持 switch 表达式（JEP 361），但遗憾的是，switch 的功能非常有限。你只能基于少数几种类型的值进行切换 —— 整型基本类型（不包括 long）、它们对应的包装类形式、枚举类型和 String 类型 —— 并且只能针对常量进行精确相等性测试。我们可能希望使用模式来针对多种可能性测试同一个变量，并对每种情况采取特定的操作，但由于现有的 switch 不支持这一点，最终我们不得不编写一连串的 if...else 测试，例如：
static String formatter(Object o) {
String formatted = "unknown";
if (o instanceof Integer i) {
formatted = String.format("int %d", i);
} else if (o instanceof Long l) {
formatted = String.format("long %d", l);
} else if (o instanceof Double d) {
formatted = String.format("double %f", d);
} else if (o instanceof String s) {
formatted = String.format("String %s", s);
}
return formatted;
}
这段代码受益于使用了 instanceof 模式表达式，但它远非完美。首先，也是最重要的一点，这种方法允许编码错误隐藏起来，因为我们使用了一个过于通用的控制结构。我们的意图是在 if...else 链的每个分支中为 formatted 赋值，但没有任何机制能够让编译器识别并验证这一不变量。如果某些代码块（可能是很少执行的代码块）没有对 formatted 进行赋值，就会产生一个 bug。（将 formatted 声明为一个空白局部变量至少可以让编译器的确定性赋值分析参与进来，但开发者并不总是会写这样的声明。）此外，上述代码无法优化；即使底层问题通常是 O(1) 的复杂度，但在缺乏编译器优化的情况下，它的时间复杂度将是 O(n)。
但是 switch 与模式匹配是完美契合的！如果我们将 switch 语句和表达式扩展到适用于任何类型，并允许 case 标签使用模式而不仅仅是常量，那么我们就可以更清晰、更可靠地重写上面的代码：
static String formatterPatternSwitch(Object o) {
return switch (o) {
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 -> o.toString();
};
}
这个 switch 的语义很明确：如果选择器表达式 o 的值与模式匹配，那么带有该模式的 case 标签就适用。（为了简洁起见，我们展示了一个 switch 表达式，但也可以展示一个 switch 语句；包括 case 标签在内的 switch 块保持不变。）
这段代码的意图更清晰，因为使用了正确的控制结构：即“参数 o 最多匹配以下条件之一，请找出并计算相应的分支。” 作为额外的好处，它是可优化的；在这种情况下，我们更有可能以 O(1) 的时间复杂度执行分派。
模式开关与空值
传统上，如果选择器表达式的结果为 null，switch 语句和表达式会抛出 NullPointerException，因此必须在 switch 外部测试 null：
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 case 标签，将 null 检查集成到 switch 中会更好：
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");
}
}
当选择器表达式的值为 null 时，switch 的行为始终由其 case 标签决定。如果存在 case null，switch 将执行与该标签关联的代码；如果没有 case null，switch 将抛出 NullPointerException，与之前的行为一致。（为了与当前 switch 语义保持向后兼容，default 标签不会匹配 null 选择器。）
我们可能希望将 null 与另一个 case 标签结合使用。例如，在以下代码中，标签 case null, String s 可以匹配 null 值以及所有的 String 值：
static void testStringOrNull(Object o) {
switch (o) {
case null, String s -> System.out.println("String: " + s);
default -> System.out.println("Something else");
}
}
案例优化
在 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 时，我们必须使用贯穿（fall-through）来获得正确的行为。（请注意 break 语句在 if 块中的精心放置位置。）
这里的问题在于，使用单一模式来区分不同情况无法扩展到单一条件之外 —— 我们需要某种方式来表达对模式的细化。一种方法是引入 受保护模式（guarded patterns），写作 p && b，它允许通过任意布尔表达式 b 对模式 p 进行细化。
我们在本 JEP 的前身中实现了受保护的模式。基于经验和反馈，我们建议改为允许在 switch 块中使用 when 子句，以指定模式标签的保护条件，例如：case Triangle t when t.calculateArea() > 100。我们将这种模式标签称为受保护的模式标签，并将布尔表达式称为保护条件。
通过这种方法，我们可以重新审视 testTriangle 代码，以直接表达大三角形的特殊情况。这样就消除了在 switch 语句中使用贯穿（fall-through）的情况，从而意味着我们可以享受简洁的箭头风格（->）规则：
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 标签。例如，我们可能希望将三角形从默认路径中分离出来；这可以通过使用两个 case 子句来实现，一个带有 guard（条件），另一个不带：
switch shape {
case .triangle where isSpecialTriangle(shape):
// 特殊三角形的处理逻辑
case .triangle:
// 普通三角形的处理逻辑
default:
// 其他形状的处理逻辑
}
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表达式的选择器表达式的类型范围，并且 -
允许在
case标签后添加可选的when子句。
为了方便起见，我们还引入了带括号的模式。
switch 标签中的模式
主要的增强功能是引入一个新的 case p 开关标签，其中 p 是一个模式。switch 的本质保持不变：选择器表达式的值会与开关标签进行比较，其中一个标签被选中，并执行或评估与该标签关联的代码。现在的区别在于，对于带有模式的 case 标签，所选标签由模式匹配的结果决定，而不是通过相等性测试。例如，在以下代码中，o 的值与模式 Long l 匹配，并评估与标签 case Long l 关联的表达式：
// 示例代码
switch (o) {
case Long l -> System.out.println("It's a Long: " + l);
default -> System.out.println("Not a Long");
}
Object o = 123L;
String formatted = switch (o) {
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 -> o.toString();
};
成功匹配模式后，我们通常会进一步测试匹配结果。这可能会导致代码变得冗长，例如：
static void test(Object o) {
switch (o) {
case String s:
if (s.length() == 1) { ... }
else { ... }
break;
...
}
}
期望的测试 —— 即 o 是一个长度为 1 的 String —— 不幸地被分在了 case 标签和接下来的 if 语句之间。
为了解决这个问题，我们通过在模式标签后支持一个可选的保护条件，引入了受保护的模式标签。这允许将上面的代码重写，使得所有条件逻辑都被提升到 switch 标签中：
static void test(Object o) {
switch (o) {
case String s when s.length() == 1 -> ...
case String s -> ...
...
}
}
第一个子句在 o 既是一个 String 且长度为 1 时匹配。第二个子句在 o 是任意长度的 String 时匹配。
只有模式标签可以带有保护条件。例如，编写带有 case 常量和保护条件的标签是无效的，例如 case "Hello" when RandomBooleanExpression()。
有时，我们需要为模式添加括号以提高可读性。因此，我们扩展了模式语言以支持书写为 (p) 的带括号的模式，其中 p 是一个模式。带括号的模式 (p) 引入了由子模式 p 所引入的模式变量。如果一个值匹配模式 p，那么它也匹配带括号的模式 (p)。
在 switch 中支持模式时，需要考虑四个主要的语言设计领域：
- 增强的类型检查
switch表达式和语句的完备性- 模式变量声明的作用域
- 处理
null的情况
1. 增强的类型检查
1a. 选择器表达式类型
在 switch 中支持模式匹配意味着我们可以放宽当前对选择器表达式的类型限制。目前，普通 switch 的选择器表达式类型必须是以下之一：一种基本整数类型（不包括 long）、其对应的包装类形式（即 Character、Byte、Short 或 Integer）、String 或 enum 类型。我们对此进行了扩展，现在要求选择器表达式的类型可以是任何基本整数类型（不包括 long）或任何引用类型。
例如，在下面的模式 switch 中，选择器表达式 o 会与涉及类类型、枚举类型、记录类型和数组类型的类型模式进行匹配，同时还有一个 null 的 case 标签和一个 default：
record Point(int i, int j) {}
enum Color { RED, GREEN, BLUE; }
static void typeTester(Object o) {
switch (o) {
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 String s 和 case CharSequence cs 都可以应用于类型为 String 的值。
需要解决的第一个问题是在这种情况下确定应该应用哪个标签。我们并没有尝试使用复杂最佳匹配方法，而是采用了更简单的语义：选择开关块中适用于某个值的第一个模式标签。
static void first(Object o) {
switch (o) {
case String s ->
System.out.println("A string: " + s);
case CharSequence cs ->
System.out.println("A sequence of length " + cs.length());
default -> {
break;
}
}
}
在此示例中，如果 o 的值属于 String 类型，则第一个模式标签将适用；如果它属于 CharSequence 类型但不属于 String 类型，则第二个模式标签将适用。
但是，如果我们将这两个模式标签的顺序交换，会发生什么呢？
static void error(Object o) {
switch (o) {
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;
}
}
}
现在，如果 o 的值是 String 类型，那么会应用 CharSequence 模式标签，因为它在 switch 块中首先出现。从某种意义上说，String 模式标签是不可达的，因为没有任何选择器表达式的值会导致它被选中。类比于不可达代码，这被视为程序员的错误，并导致编译时错误。
更准确地说，我们说第一个模式标签 case CharSequence cs 主导 了第二个模式标签 case String s，因为每一个匹配模式 String s 的值同样也能匹配模式 CharSequence cs，但反之则不成立。这是由于第二个模式的类型 String 是第一个模式类型 CharSequence 的子类型。
一个未受保护的模式标签主导了具有相同模式的受保护模式标签。例如，（未受保护的）模式标签 case String s 主导了受保护的模式标签 case String s when s.length() > 0，因为每个匹配模式标签 case String s when s.length() > 0 的值都必须匹配模式标签 case String s。
一个带有保护条件的模式标签仅在其模式支配另一个模式（无论是带有保护条件还是不带保护条件）且其保护条件为值为 true 的常量表达式时，才能支配另一个模式标签。例如，带有保护条件的模式标签 case String s when true 支配模式标签 case String s。我们不会进一步分析保护条件表达式，以更精确地确定哪些值与该模式标签匹配（这是一个通常无法判定的问题）。
模式标签可以支配常量标签。例如，模式标签 case Integer i 支配常量标签 case 42，而当 A 是枚举类类型 E 的枚举常量时，模式标签 case E e 支配常量标签 case A。如果相同的模式标签在没有 when 子句的情况下支配常量标签，那么带有守卫的模式标签也支配该常量标签。换句话说，我们不检查守卫条件，因为这在一般情况下是不可判定的。例如，模式标签 case String s when s.length() > 1 支配常量标签 case "hello"，这是符合预期的；但是 case Integer i when i != 0 支配标签 case 0。
所有这些都表明，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
}
编译器会检查所有标签。在 switch 块中，如果某个标签被该 switch 块中较早出现的标签所支配（dominated），则会产生编译时错误。这一支配要求确保了，如果一个 switch 块仅包含类型模式的 case 标签，它们将按照子类型顺序出现。
（支配的概念类似于 try 语句中对 catch 子句的条件要求，如果捕获异常类 E 的 catch 子句前面存在一个能够捕获 E 或 E 的超类的 catch 子句，则会导致错误（JLS §11.2.3）。从逻辑上讲，前面的 catch 子句支配了后面的 catch 子句。）
如果 switch 表达式或 switch 语句的 switch 块中存在多个匹配所有情况的开关标签（match-all switch label），这同样会导致编译时错误。匹配所有情况的标签包括 default 和模式标签，其中模式无条件地匹配选择器表达式。例如，类型模式 String s 会无条件地匹配类型为 String 的选择器表达式，而类型模式 Object o 则会无条件地匹配任何引用类型的选择器表达式。
2. switch 表达式和语句的完备性
switch 表达式要求在 switch 块中处理选择器表达式的所有可能值；换句话说，它是 穷尽的。这保证了 switch 表达式成功求值后总会产生一个值。对于普通的 switch 表达式，这是通过对 switch 块施加一组相当直接的额外条件来强制执行的。
对于模式 switch 表达式和语句，我们通过定义一个开关块中开关标签的 类型覆盖 概念来实现这一点。然后将开关块中所有开关标签的类型覆盖合并起来，以确定开关块是否穷尽了选择器表达式的所有可能性。
考虑以下（错误的）模式 switch 表达式：
static int coverage(Object o) {
return switch (o) { // Error - not exhaustive
case String s -> s.length();
};
}
该 switch 块只有一个 switch 标签，即 case String s。这会匹配选择器表达式中类型为 String 的任何子类型的值。因此，我们说此 switch 标签的类型覆盖范围是 String 的所有子类型。这个模式 switch 表达式并不完整，因为其 switch 块的类型覆盖范围（String 的所有子类型）并未包含选择器表达式的类型（Object）。
考虑这个（仍然错误的）例子：
static int coverage(Object o) {
return switch (o) { // Error - still not exhaustive
case String s -> s.length();
case Integer i -> i;
};
}
此 switch 块的类型覆盖范围是其两个 switch 标签覆盖范围的并集。换句话说，类型覆盖范围包括 String 的所有子类型集合和 Integer 的所有子类型集合。但是，类型覆盖范围仍然不包括选择器表达式的类型，因此这种模式的 switch 表达式同样不是穷尽的，并会导致编译时错误。
default 标签的类型覆盖了所有类型，所以这个例子（终于！）是合法的：
static int coverage(Object o) {
return switch (o) {
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，因此这个 switch 块是穷尽的。结果就是，不需要 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，但编译器可以检测到，由于选择器表达式属于类型 I<Integer>，因此开关块只需要覆盖类 B 即可做到详尽无遗。
为了防止独立编译不兼容的问题，在这种情况下，针对一个密封类的 switch 语句，如果 switch 块是详尽无遗的且没有匹配所有情况的默认分支，编译器会自动添加一个 default 标签，其代码会抛出 IncompatibleClassChangeError 异常。只有当密封接口被修改且 switch 代码未重新编译时，才会执行到这个标签。实际上，编译器在为你强化代码的健壮性。
这种详尽性条件适用于模式 switch 表达式和模式 switch 语句。为了确保向后兼容，所有现有的 switch 语句都将保持不变地编译。但如果一个 switch 语句使用了此 JEP 中详细说明的任何 switch 增强功能，那么编译器将检查其是否详尽。（Java 语言的未来编译器可能会对非详尽的旧版 switch 语句发出警告。）
更准确地说，任何使用模式或 null 标签的 switch 语句，或者其选择表达式不是旧类型（char、byte、short、int、Character、Byte、Short、Integer、String 或枚举类型）之一时，都要求具备完备性。例如：
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;
};
}
使大多数 switch 语句变得详尽无遗，只需在 switch 块的末尾添加一个简单的 default 子句即可。这会使代码更加清晰且易于验证。例如，以下模式中的 switch 语句并不详尽，因此是错误的：
Object o = ...
switch (o) { // Error - not exhaustive!
case String s:
System.out.println(s);
break;
case Integer i:
System.out.println("Integer");
break;
}
它可以被彻底地制作出来：
Object o = ...
switch (o) {
case String s:
System.out.println(s);
break;
case Integer i:
System.out.println("Integer");
break;
default: // Now exhaustive!
break;
}
由于 record 模式（JEP 405）支持在其内部嵌套其他模式，这使得穷尽性的概念变得更加复杂。因此，穷尽性的概念必须反映这种潜在的递归结构。
3. 模式变量声明的范围
模式变量（JEP 394）是由模式声明的局部变量。模式变量声明的特殊之处在于其作用域是流敏感的。以下面的例子回顾一下，其中类型模式 String s 声明了模式变量 s：
static void test(Object o) {
if ((o instanceof String s) && s.length() > 3) {
System.out.println(s);
} else {
System.out.println("Not a string");
}
}
s 的声明在 && 表达式的右侧操作数以及“then”块中是有效的。然而，它在“else”块中无效；为了使控制流转移到“else”块，模式匹配必须失败，在这种情况下，模式变量将不会被初始化。
我们将这种对模式变量声明的流敏感作用域概念扩展到包含 case 标签中出现的模式声明，并通过三条新规则来实现：
-
模式变量声明的作用域如果出现在
switch标签中，则包括该标签的任何when子句。 -
出现在
switch规则的case标签中的模式变量声明，其作用域包括箭头右侧出现的表达式、代码块或throw语句。 -
出现在
switch带标签语句组的case标签中的模式变量声明，其作用域包括该语句组的块语句。禁止贯穿声明了模式变量的case标签。
这个示例展示了第一条规则的实际应用：
static void test(Object o) {
switch (o) {
case Character c
when c.charValue() == 7:
System.out.println("Ding!");
break;
default:
break;
}
}
}
模式变量 c 的声明范围包括 switch 标签的 when 表达式。
此变体展示了第二条规则的实际应用：
static void test(Object o) {
switch (o) {
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 o) {
switch (o) {
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 语句组中的语句，即使第一个语句组的执行可以贯穿 default 开关标签并执行这些语句。
我们禁止通过声明模式变量的 case 标签的可能性。考虑以下错误示例：
static void test(Object o) {
switch (o) {
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;
}
}
如果允许这样做，并且选择器表达式 o 的值为 Character 类型，那么在执行 switch 块时可能会跳过第二个语句组（在 case Integer i: 之后），此时模式变量 i 可能尚未被初始化。因此，允许执行流程跳过声明了模式变量的 case 标签将导致编译时错误。
这就是为什么不允许由多个模式标签组成的 switch 标签，例如 case Character c: case Integer i: ...。类似的推理也适用于禁止在单个 case 标签中使用多个模式：无论是 case Character c, Integer i: ... 还是 case Character c, Integer i -> ... 都不被允许。如果允许这样的 case 标签，那么在冒号或箭头之后，c 和 i 都会处于作用域中，但根据 o 的值是 Character 或 Integer，它们中只有一个会被初始化。
另一方面，如本例所示，跳过未声明模式变量的标签是安全的：
void test(Object o) {
switch (o) {
case String s:
System.out.println("A string");
default:
System.out.println("Done");
}
}
4. 处理 null
4a. 匹配 null
传统上，如果选择器表达式的结果为 null，switch 语句会抛出 NullPointerException。这种行为是广为人知的，我们并不建议对任何现有的 switch 代码进行更改。
然而，鉴于模式匹配和 null 值存在合理且不含异常的语义，我们有机会使模式 switch 更加对 null 友好，同时仍然与现有的 switch 语义保持兼容。
首先，我们为 case 引入一个新的 null 标签。然后，我们取消了这样一条通用规则：即如果选择器表达式的值为 null，switch 语句会立即抛出 NullPointerException 异常。相反，我们会检查 case 标签以确定 switch 的行为：
-
如果选择器表达式的计算结果为
null，则任何null的 case 标签被视为匹配。如果 switch 块中没有与此类标签关联，则switch会抛出NullPointerException，与之前相同。 -
如果选择器表达式的计算结果为非
null值，则我们正常选择一个匹配的case标签。如果没有case标签匹配，则任何default标签都被认为是匹配的。
例如，给定下面的声明，计算 test(null) 会打印 null! 而不是抛出 NullPointerException 异常：
static void test(Object o) {
switch (o) {
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 o) {
switch (o) {
case String s -> System.out.println("String: " + s);
case Integer i -> System.out.println("Integer");
default -> System.out.println("default");
}
}
等价于：
static void test(Object o) {
switch (o) {
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 中的区别在于，你可以在 switch 内部直接处理这种情况，而不是在外部处理。如果你在 switch 块中看到一个 null 标签，那么这个标签将匹配一个 null 值。如果你在 switch 块中没有看到 null 标签，那么对 null 值进行 switch 操作时会像以前一样抛出 NullPointerException 异常。
4b. 由 null 标签引起的新标签形式
从 Java 16 开始，switch 块支持两种风格：一种基于标记的语句组（: 形式），其中允许贯穿；另一种基于单结果形式（-> 形式），其中不允许贯穿。在前一种风格中，多个标签通常写作 case l1: case l2:，而在后一种风格中，多个标签写作 case l1, l2 ->。
支持 null 标签意味着可以在 : 形式中表达一些特殊情况。例如：
Object o = ...
switch (o) {
case null: case String s:
System.out.println("String, including null");
break;
...
}
开发者有理由认为 : 和 -> 形式具有相同的表达能力，并且如果前者支持 case A: case B:，那么后者也应该支持 case A, B ->。因此，前面的例子表明我们应该支持 case null, String s -> 标签，如下所示：
Object o = ...
switch (o) {
case null, String s -> System.out.println("String, including null");
...
}
当 o 为 null 引用或者是一个 String 时，o 的值与此标签匹配。在这两种情况下，模式变量 s 都会使用 o 的值进行初始化。（反向形式 case String s, null 也是允许的，且行为完全相同。）
将 null 情况与 default 标签结合使用也是有意义的，并且并不罕见，即：
Object o = ...
switch (o) {
...
case null: default:
System.out.println("The rest (including null)");
}
同样，这应该在 -> 形式中得到支持。为此，我们引入了一个新的 default 情况标签：
Object o = ...
switch (o) {
...
case null, default ->
System.out.println("The rest (including null)");
}
如果 o 的值为 null 引用值，或者没有其他标签匹配，那么 o 的值与此标签匹配。
未来工作
-
目前，模式
switch不支持原始类型boolean、long、float和double。它们的实用性似乎很小，但将来可能会添加对这些类型的支持。 -
我们预计，在未来，通用类将能够声明解构模式以指定它们如何进行匹配。这样的解构模式可以与模式
switch一起使用，从而生成非常简洁的代码。例如，如果我们有一个Expr的层次结构，并且其子类型包括IntExpr（包含单个int）、AddExpr和MulExpr（包含两个Expr），以及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子句。