<div dir="ltr"> The question's emphasis is wrong.<br>" The compiler is autoboxing the int, x, to<br>create an Integer object, which always matches the first case."<br>But, the selector expression is not significant. It is the case label patterns that determine if the type of a case label pattern is a subtype of the type of another case label pattern that appears before it.<br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Sep 5, 2025 at 4:17 PM David Alayachew <<a href="mailto:davidalayachew@gmail.com">davidalayachew@gmail.com</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"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Puzzlers aside, can we get a definitive answer on why this is this way? I want to understand the semantics by the compiler that made this possible, so that I can understand why it is being considered legal by the compiler. Is what Deepak says is true?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 5, 2025 at 12:46 PM Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</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">----- Original Message -----<br>
> From: "Brian Goetz" <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>><br>
> To: "Simon Ritter" <<a href="mailto:sritter@azul.com" target="_blank">sritter@azul.com</a>>, "amber-dev" <<a href="mailto:amber-dev@openjdk.org" target="_blank">amber-dev@openjdk.org</a>><br>
> Sent: Friday, September 5, 2025 4:30:06 PM<br>
> Subject: Re: Question on Primitive Types in Patterns<br>
<br>
>><br>
>> I've been giving a presentation on Patterns in the Java language and<br>
>> including some puzzles.  The recent inclusion of Primitive Types in<br>
>> Patterns has provided some interesting material.  I currently have one<br>
>> puzzle that I can't quite explain; hopefully someone on the mailing<br>
>> list can provide clarification.<br>
> <br>
> On a pedagogical note, I'd like to make a case for "Java Puzzlers Talks<br>
> Considered Harmful."  They can be fun to write (which is why we get so<br>
> many of them), but I have found that the vast majority of time, a good<br>
> chunk of the audience comes away with notions that are closer to "XYZ is<br>
> broken", "XYZ is just all ad-hoc complexity", or "XYZ has no organizing<br>
> design principle" -- even though this is rarely the intent of the<br>
> presenter (often the opposite, in fact.)<br>
> <br>
> When Josh and Neal started with Puzzlers, they could at least come from<br>
> the position of "these were some arguably-mistakes that *we* made".  Not<br>
> only did this give them credibility that almost no other "Java Puzzlers"<br>
> presenter could have, but it pushed them to dig deeper to present<br>
> language design tradeoffs _from the perspective of language designers_.<br>
> <br>
> I cannot count the number of times where someone has seen a "puzzler"<br>
> presentation or blog, and learned the exact opposite lesson than it was<br>
> trying to teach.   This is an extraordinarily difficult format for<br>
> teaching.  Worse, the nature of a "Puzzlers" talk requires having a<br>
> bunch of them, and -- even when Josh and Neal did it -- there were<br>
> always a few that didn't live up to the standards; the format often<br>
> overtakes the message.  It is just a truly punishing format, one that<br>
> requires world-class pedagogy and impeccable preparation to avoid the<br>
> all-too-common outcome where many in the audience learn the wrong lesson<br>
> (often reinforcing their preconceived but ill-examined assumptions about<br>
> "X is bad.")<br>
<br>
This is a preview feature, so for me finding corner cases is fair game.<br>
It help us to understand the tradeoffs of this feature.<br>
<br>
There are always puzzlers, for every features, but there are two categories of puzzlers:<br>
- those that enlighten you (like this is why Foo behave different as a top level pattern or as an inner pattern),<br>
  as you said, it's quite hard to convey that in a presentation.<br>
- those that just show the designers being too clever (lets make ?: boxing rules different)<br>
  or the feature being consistent only with itself and not with the rest of the world (the X cross Y problem).<br>
<br>
regards,<br>
Rémi<br>
</blockquote></div>
</blockquote></div>