Are you using a Java version that supports pattern matching for switch (JDK
17+ as a preview feature, standardized in JDK 21)? Or, it is a bug.
On Fri, Sep 5, 2025 at 7:09 AM Simon Ritter <srit...@azul.com> wrote:
> Hi,
> I've been giving a presentation on Patterns in the Java language and
> including some puzzles. The recent inclusion of Primitive Types in
> Patterns has provided some interesting material. I currently have one
> puzzle that I can't quite explain; hopefully someone on the mailing list
> can provide clarification.
>
> Let's start with this simple example:
>
> int x = getX(); // x is 42
>
> switch (x) {
> case byte b -> System.out.println("byte");
> case int i -> System.out.println("int");
> }
>
> Here we have a runtime check, which establishes that the conversion from
> int to byte is exact, as there is no loss of information.
>
> If we reverse the order of the cases:
>
> switch (x) {
> case int i -> System.out.println("int");
> case byte b -> System.out.println("byte");
> }
>
> The code will not compile, as the int case dominates the byte case.
>
> So far, so good.
>
> However, if we change the int case to use a wrapper class:
>
> switch (x) {
> case Integer i -> System.out.println("int");
> case byte b -> System.out.println("byte");
> }
>
> the code will compile and the result is 'int'.
>
> If I look at JEP 507, under the section on Safety of conversions, it
> states that "...boxing conversions and widening reference conversions
> are unconditionally exact." The compiler is autoboxing the int, x, to
> create an Integer object, which always matches the first case.
>
> What I can't explain is why the compiler does not still see this as
> pattern dominance? No value of x will ever result in the switch
> matching on byte so the code is unreachable.
>
> Thanks in advance,
>
> Simon.
>
