Summary

JEP 456 introduced unnamed variables & patterns in the Java language. Unnamed variables in patterns (pattern variables), since they elide the names of the corresponding bindings, they allow multiple patterns to appear in the same case or in multiple blocks with fall-through if and only if it is only unnamed pattern variables that are introduced. The following case labels are some valid examples case R2 _, R3 _, R4 _->, case Box(R2 _), Box(var _) :, case Box(R1 _), Box(R2 _) -> and case Box(R3 _), Box(_). Similarly, the following switch statement with a valid fall-through (since no variables are introduced):

    switch (o) {
        case Integer _:
        case Number _:
            return 1;
        default:
            return 2;
    }

All the aforementioned are examples that use unnamed patterns and type patterns with unnamed variables that javac accepts and JLS allows.

javac correctly raises compile-time errors in the following cases:

    switch (o) {
        case Integer i, String _ -> // error
                System.out.println("named/unnamed");
        ...
    }

    switch (o) {
        case Integer _, String s ->  // error
                System.out.println("unnamed/named");
        ...
    }

    switch (o) {
        case PairIS(_, _), String s ->  // error
                System.out.println("unnamed patterns/named");
        ...
    }

Problem

A current compiler bug in javac allows the following shape of code when a variable is introduced in a nested position among unnamed patterns and type patterns with unnamed pattern variables.

    public class X {
    record Point (int x, int y) {}
    static void foo(Object o) {
        switch (o) {
            case Integer _, Point(int x, int _), String _  :
                System.out.println("Integer");
            default:
                System.out.println("Object");
        }
    }
    public static void main(String [] args) {
        foo("");
    }
}

This program is erroneously accepted and it is not allowed by the JLS.

Solution

javac will be updated to correctly follow the JLS, and will produce compile-time error for switch case clauses which contain multiple case labels and also produce a binding. Also similar cases with fall-through from one case clause to another will produce compile-time error as per JLS.

Specification

There are not JLS changes associated with this.