From angelos.bimpoudis at oracle.com Fri Oct 3 21:48:52 2025 From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis) Date: Fri, 3 Oct 2025 21:48:52 +0000 Subject: Draft JEP: Primitive Types in Patterns, instanceof, and switch (Fourth Preview) Message-ID: 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: From angelos.bimpoudis at oracle.com Fri Oct 3 23:18:23 2025 From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis) Date: Fri, 3 Oct 2025 23:18:23 +0000 Subject: Draft JEP: Primitive Types in Patterns, instanceof, and switch (Fourth Preview) In-Reply-To: References: Message-ID: Confidential ? Oracle Internal This line was user error, please ignore. ________________________________ From: Angelos Bimpoudis Sent: 03 October 2025 23:48 To: 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: From angelos.bimpoudis at oracle.com Thu Oct 16 14:47:05 2025 From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis) Date: Thu, 16 Oct 2025 14:47:05 +0000 Subject: Towards a Future-Proof Chapter 5: A JLS Refactoring Initiative Message-ID: Hello amber-dev, amber-spec-experts, I wanted to share some emerging thoughts and possible directions regarding the flexibility and expressiveness of conversions in the Java language. Given recent interest in the positioning of conversions in JEP 507, it seemed a timely opportunity to share this ongoing analysis. This is especially relevant as Java continues to evolve its pattern matching facilities and looks ahead to Project Valhalla. The framework proposed by JEP 507 is more than just a cleanup of existing rules. It's a necessary precursor as the language moves towards enabling user-defined conversions and supporting richer numeric types. These planned features will fundamentally expand how values can be expressed and composed in Java. For a look ahead, I recommend these recent JVMLS presentations: * Growing the Java Language * Paths to Support Additional Numeric Types on the Java Platform As we continue to evolve towards value types and numeric types, it becomes clear that the framework for conversions, which stood us well when we only had eight primitive types, needs to be shored up somewhat. Attached is a rough exploration of the issues surrounding shoring up the framework for conversions so that it can support these new directions for Java: * Towards a Future-Proof Chapter 5: A JLS Refactoring Initiative Best regards, Angelos -------------- next part -------------- An HTML attachment was scrubbed... URL: