Draft JEP: Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

[Angelos Bimpoudis]

Confidential – Oracle Internal
This line was user error, please ignore.

________________________________
From: Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
Sent: 03 October 2025 23:48
To: amber-spec-experts at openjdk.org <amber-spec-experts at openjdk.org>
Subject: Draft JEP: Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

Dear experts,

We are preparing to re-preview primitive types in patterns, instanceof, and switch for a fourth time (currently previewed in JEP 507). You can read the draft JEP here:

https://openjdk.org/jeps/8359136

We are grateful for the feedback that we have received from our expert and developer communities during the previous rounds. The proposed changes enhance the definition of unconditional exactness and apply tighter dominance checks in switch. These changes enable the compiler to identify a wider range of mistakes by developers, although a small number of switch constructs that were previously legal will now be rejected.

In more detail, firstly, we intend to expand the set of the existing unconditionally exact conversions (type-based unconditionally exact conversions) with value-based unconditionally exact conversions. Making unconditional exactness aware of constant expressions and passing such information to dominance, allows to implement tighter checks:

int j = ...;
switch(j) {
    case float f    -> {}
    case 16_777_216 -> {}   // error: dominated (the conversion from int to float for that constant is unconditionally exact)
    default         -> {}
}

Secondly, we treat switches that contain unconditional patterns that are followed by other patterns, as erroneous:

int x = ...;
switch(x) {
    case int _      -> {}
    case float _    -> {}  // error: dominated (even if both i2f and f2i are both NP conversions)
}

int i = ...;
switch (i) {
    case Integer _ -> {}
    case byte _    -> {}  // error: dominated (even if there is no byte to Integer conversion)
};

interface A {}
interface B {}
A aa = ...;
switch (aa) {
    case A _       -> {}
    case B _       -> {}  // error: dominated (even if A and B are unrelated)
}

Note that the last case is valid code today (prior to this JEP). A user that wrote case A followed by case B is not aware that case B is never matched; case A is unconditional for the type of the selector which is A.

Comments welcome!

Thanks,
Angelos


Confidential – Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20251003/1ebfb255/attachment.htm>