Draft JLS Spec about unnamed patterns and variables

Angelos Bimpoudis angelos.bimpoudis at oracle.com
Tue Feb 28 16:21:34 UTC 2023

Updated draft spec.

Includes a small number of fixes and a correct "rebase" on top of the JLS changes resulting from JEP 432 (Record Patterns (Second Preview)) and JEP 433 (Pattern Matching for switch (Fourth Preview)) that covers Maurizio's point.


(please note that the based URL has been slightly changed ^^)

Comments are always very much welcomed!


From: Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
Sent: 24 February 2023 17:23
To: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>; Brian Goetz <brian.goetz at oracle.com>; amber-spec-experts <amber-spec-experts at openjdk.java.net>
Subject: Re: Draft JLS Spec about unnamed patterns and variables

The main takeaways:

  *   case Number _ can fall out to other patterns since it doesn't introduce any bindings (adjustment in the spec draft is needed)
  *   case Number _ dominates case String _, Integer _ (adjustment is not needed in current draft, but I will double check before I circulate the revised version).

Thanks for all the comments!
Thought experiment: what if we had union type patterns?  Then the case label `case String _, Integer _` would be like matching the the union type pattern `(String|Integer) _`:

    case Number n: ...
    case (String|Integer) _: ...

Would javac then complain that `String|Integer` could be simplified to just `String` on the bsais of flow analysis?  (IntelliJ would, of course.)

I initially thought as Tagir did, but then Gavin turned me around and reminded me that it was not dead code, but unreachable statements that we try to avoid.  So now I am torn...
Would union type patterns imply the existence of union types? If yes, then, the second case could even exist with a binding, correct? In your example the LUB is Object so even the case (String|Integer) x : x.getClass() can work. The difficult scenario would arise with the case (Customer|Human) x : x.getName();

If the first case in your example did not introduce a binding, would both case be equal with Number | (String | Integer)? Union types a la Ceylon support this (http://web.mit.edu/ceylon_v1.3.3/ceylon-1.3.3/doc/en/spec/html_single/#uniontypes). On the other hand in Ceylon, the switch needs to be exhaustive and​ all cases need to be disjoint. So this switch would be invalid. hm..

From: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
Sent: 23 February 2023 20:27
To: Brian Goetz <brian.goetz at oracle.com>; Angelos Bimpoudis <angelos.bimpoudis at oracle.com>; amber-spec-experts <amber-spec-experts at openjdk.java.net>
Subject: Re: Draft JLS Spec about unnamed patterns and variables

On 23/02/2023 18:46, Brian Goetz wrote:
but we really wanted the case merging.


I just wanted to point out that there are two questions here (one about fall-through and one about domination), and when reading the emails it was not obvious to me that a change in how fall-through was defined was being proposed.

If merging unrelated type tests is a goal, I think there should be an example for it in the JEP under "Motivation".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20230228/05bb4558/attachment-0001.htm>

More information about the amber-spec-experts mailing list