<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Got it, ty vm.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I had assumed that Byte to Integer was already implemented logic. I had heard that discussion in Valhalla many times.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Ok, makes perfect sense now. So, when Valhalla reevaluates the relationship between the various wrapper classes, this might change?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 22, 2024 at 5:41 AM Aggelos Biboudis <<a href="mailto:abimpoudis@openjdk.org">abimpoudis@openjdk.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 20 May 2024 08:26:43 GMT, Aggelos Biboudis <<a href="mailto:abimpoudis@openjdk.org" target="_blank">abimpoudis@openjdk.org</a>> wrote:<br>
<br>
> It seems that the compiler introduced a rule that does not exist in the spec. The fix is simple, and it will fix the behaviour of JDK 23 according to the spec. For example the following is accepted by JDK 22 and needs to continue to be accepted by JDK 23:<br>
> <br>
> <br>
> public static int test() {<br>
>     Byte i = (byte) 42;<br>
>     return switch (i) {<br>
>         case Byte ib   -> 1;<br>
>         case (short) 0 -> 2; // OK - not dominated<br>
>     };<br>
> }<br>
> <br>
> <br>
> Similarly for primitive type patterns:<br>
> <br>
> <br>
> public static int test() {<br>
>     Byte i = (byte) 42;<br>
>     return switch (i) {<br>
>         case Byte ib  -> 1;<br>
>         case short s  -> 2; // Also not dominated since there is no unconditionally exact conversion from short to Byte<br>
>     };<br>
> }<br>
> <br>
> public static int test() {<br>
>     int i = 42;<br>
>     return switch (i) {<br>
>         case Integer ib -> 1;<br>
>         case byte ip    -> 2; // Also not dominated since there is no unconditionally exact conversion from byte to Integer<br>
>     };<br>
> }<br>
<br>
While `byte` --> `Byte` is boxing indeed, `Byte` --> `Integer` is  not a widening reference conversion. From the spec:<br>
<br>
> A widening reference conversion exists from any reference type S to any reference type T, provided S is a subtype of T (§4.10).<br>
<br>
and<br>
<br>
> A class or interface is disjoint from another class or interface if it can be determined statically that they have no instances in common (other than the null value)<br>
<br>
The two reference types in the second conversion are disjoint. Evident that you cannot even ask if a Byte is instanceof Integer.<br>
<br>
<br>
jshell> Byte b = 42<br>
b ==> 42<br>
<br>
jshell> b instanceof Integer<br>
|  Error:<br>
|  incompatible types: java.lang.Byte cannot be converted to java.lang.Integer<br>
|  b instanceof Integer<br>
|  ^<br>
<br>
<br>
What you are really asking is whether or not `Byte` can be converted to `Integer` since we know that both can be null and also all possible reference values of the first also belong to the domain of the second. So actually maybe null is the only problematic value (because it witnesses that both types are reference types)? Today we manage conversions by those tables in Chapter 5. With the arrival of valhalla we will need to think what place the conversion of Byte! to Integer! has. (a `Byte` will be a null-widened `Byte!`.<br>
<br>
-------------<br>
<br>
PR Comment: <a href="https://git.openjdk.org/jdk/pull/19301#issuecomment-2124327985" rel="noreferrer" target="_blank">https://git.openjdk.org/jdk/pull/19301#issuecomment-2124327985</a><br>
</blockquote></div>