[External] : Re: New candidate JEP: 456: Unnamed Variables and Patterns

Remi Forax forax at univ-mlv.fr
Wed Sep 27 13:59:35 UTC 2023


> From: "Angelos Bimpoudis" <angelos.bimpoudis at oracle.com>
> To: "Clément BOUDEREAU" <cboudereau at gmail.com>, "Gavin Bierman"
> <gavin.bierman at oracle.com>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "Tagir Valeev" <amaembo at gmail.com>,
> "amber-dev" <amber-dev at openjdk.org>, "amber-spec-experts"
> <amber-spec-experts at openjdk.org>
> Sent: Wednesday, September 27, 2023 3:33:26 PM
> Subject: Re: [External] : Re: New candidate JEP: 456: Unnamed Variables and
> Patterns

> Hello Clement!

> Thanks for letting us know. I recreated a stand alone reproduction of your
> report and indeed I get the verification error: [
> https://bugs.openjdk.org/browse/JDK-8317048 |
> https://bugs.openjdk.org/browse/JDK-8317048 ]
> Looking into it.

> Angelos

Hello Angelos, 
you can also log another bug, it seems that javac allows "final" in front of a record pattern, something which is not allowed by the grammar (and also rightfully rejected by IntelliJ). 

record Foo ( int x) {} 

public static void main ( String [] args ) { 
Object o = args ; 
switch ( o ) { 
case final Foo( int x) -> {}   // oops ! 
default -> {} 
} 
} 

regards, 
Rémi 

> From: Clément BOUDEREAU <cboudereau at gmail.com>
> Sent: 27 September 2023 09:55
> To: Gavin Bierman <gavin.bierman at oracle.com>
> Cc: Brian Goetz <brian.goetz at oracle.com>; Tagir Valeev <amaembo at gmail.com>;
> amber-dev at openjdk.org <amber-dev at openjdk.org>; Angelos Bimpoudis
> <angelos.bimpoudis at oracle.com>; amber-spec-experts
> <amber-spec-experts at openjdk.org>
> Subject: [External] : Re: New candidate JEP: 456: Unnamed Variables and Patterns
> Hi Amber dev team,

> Firstly, thank you for the awesome work done.

> I tried to use unnamed variable to simplifiy pattern matching in existing code
> with preview feature enable and JDK21 but ended up with runtime exception. The
> code compiles but unit test fails while I am actually running unit test with
> other preview feature.

> Here is the PR with the problem and temporary workaround :
> [
> https://urldefense.com/v3/__https://github.com/cboudereau/dataseries/pull/34__;!!ACWV5N9M2RV99hQ!IQaUoSdPFw6-k9Xl8bh66a2ULWyr2pCGqHgDBldDFjJNesjswhMSNWPshaJor8k95x4FVDPHBA2WQlMKyak3HQUSGQ$
> | https://github.com/cboudereau/dataseries/pull/34 ]

> FYI, I have another pull request to integrate as soon as possible preview
> feature of the latest jdk21 here where everything work fine locally :
> [
> https://urldefense.com/v3/__https://github.com/cboudereau/dataseries/pull/24__;!!ACWV5N9M2RV99hQ!IQaUoSdPFw6-k9Xl8bh66a2ULWyr2pCGqHgDBldDFjJNesjswhMSNWPshaJor8k95x4FVDPHBA2WQlMKyakzNtsm5g$
> | https://github.com/cboudereau/dataseries/pull/24 ]

> Here is the error at runtime:

> [ERROR] SimpleTest.simple:17 ┬╗ Verify Bad local variable type
> Exception Details:
> Location:
> io/github/cboudereau/dataseries/Union$Value.compareTo(Lio/github/cboudereau/dataseries/Union$Value;)I
> @297: aload
> Reason:
> Type top (current frame, locals[9]) is not assignable to reference type
> Current Frame:
> bci: @297
> flags: { }
> locals: { 'io/github/cboudereau/dataseries/Union$Value',
> 'io/github/cboudereau/dataseries/Union$Value', '[Z',
> 'io/github/cboudereau/dataseries/Union$Value$Tuple', integer,
> 'io/github/cboudereau/dataseries/Union$Value$Tuple', top, top, top, top, top,
> 'io/github/cboudereau/dataseries/Union$Value$Fixed',
> 'io/github/cboudereau/dataseries/Union$Value', integer,
> 'io/github/cboudereau/dataseries/Union$Value', integer }
> stack: { }
> Bytecode:
> 0000000: 1278 c000 7a4d bb00 0c59 2a2b b700 0e59
> 0000010: b800 1157 4e03 3604 2c05 0454 2d15 04ba
> 0000020: 0017 0000 ab00 0000 0000 0014 0000 0001
> 0000030: 0000 0000 0000 0022 bb00 1b59 0101 b700
> 0000040: 1d2c 0604 54bf 2d3a 0519 052c 0704 54b6
> 0000050: 0020 c000 243a 0c2c 0804 5403 360d 2c10
> 0000060: 0604 5419 0c15 0dba 0026 0000 aa00 0000
> 0000070: 0000 00df ffff ffff 0000 0001 0000 00df
> 0000080: 0000 001c 0000 006d 1905 2c10 0704 54b6
> 0000090: 0027 c000 243a 0e03 360f 190e 150f ba00
> 00000a0: 2600 00aa 0000 002b ffff ffff 0000 0001
> 00000b0: 0000 002b 0000 0019 0000 0022 032c 1008
> 00000c0: 0454 a700 9404 2c10 0904 54a7 008b 0436
> 00000d0: 0d2c 100a 0454 a7ff 8d19 052c 100b 0454
> 00000e0: b600 27c0 0024 3a0e 2c10 0c04 5403 360f
> 00000f0: 190e 150f ba00 2600 00aa 0000 0000 0047
> 0000100: ffff ffff 0000 0001 0000 0047 0000 001b
> 0000110: 0000 0024 022c 100d 0454 a700 3c19 0ec0
> 0000120: 0001 3a0b 2c10 0e04 5419 09b4 002a 190b
> 0000130: b400 2ab9 002e 0200 2c10 0f04 54a7 0019
> 0000140: 0536 0d2c 1010 0454 a7ff 1b04 3604 2c10
> 0000150: 1104 54a7 fec9 2c10 1204 54ac 4ebb 001b
> 0000160: 592d b600 362d b700 1d2c 1013 0454 bf
> Exception Handler Table:
> bci [75, 82] => handler: 348
> bci [138, 146] => handler: 348
> bci [219, 227] => handler: 348
> Stackmap Table:
> append_frame(@28,Object[#122],Object[#12],Integer)
> same_frame(@56)
> same_frame(@70)
> full_frame(@99,{Object[#36],Object[#36],Object[#122],Object[#12],Integer,Object[#12],Top,Top,Top,Top,Top,Top,Object[#36],Integer},{})
> same_frame(@136)
> append_frame(@154,Object[#36],Integer)
> same_frame(@188)
> same_frame(@197)
> same_frame(@206)
> chop_frame(@217,2)
> append_frame(@240,Object[#36],Integer)
> same_frame(@276)
> same_frame(@285)
> same_frame(@320)
> chop_frame(@331,2)
> full_frame(@342,{Object[#36],Object[#36],Object[#122]},{Integer})
> same_locals_1_stack_item_frame(@348,Object[#52])

> On Tue, Sep 26, 2023 at 6:14 PM Gavin Bierman < [
> mailto:gavin.bierman at oracle.com | gavin.bierman at oracle.com ] > wrote:

>> That’s right. We made a decision to simplify the grammar of switch labels for
>> the JEP to only have a single pattern. However, if you use the "colon form” you
>> can express similar code:

>> gmb at gmb-mac src % cat Switch.java
>> public class Switch {

>> sealed interface X { }

>> enum E implements X {A;}

>> record R() implements X { }

>> public void work(X x) {
>> var result = switch (x) {
>> case E.A:
>> case R(): yield 42;
>> // exhaustive!
>> };
>> }

>> public static void main(String[] args) {
>> System.out.println("complete");
>> }
>> }
>> gmb at gmb-mac src % java Switch.java
>> complete

>> As you point out, a more uniform treatment would treat all constants as patterns
>> and allow them all to appear in pattern lists of record patterns, for example.
>> Working on it!!

>> Gavin

>>> On 26 Sep 2023, at 14:52, Brian Goetz < [ mailto:brian.goetz at oracle.com |
>>> brian.goetz at oracle.com ] > wrote:

>>> I see now I answered a slightly different question :)

>>> We do support case labels for enums in pattern switches, and they participate in
>>> exhaustiveness. But we don't currently support mixing `case pattern,
>>> constant-label` in a single case label. This is waiting for a more
>>> comprehensive treatment of constants as patterns.

>>> On 9/26/2023 8:32 AM, Tagir Valeev wrote:

>>>> Hello! As we are finalizing this feature, can we squeeze in a little
>>>> improvement? Namely, support enum and patterns within the same case
>>>> label, provided that the patterns do not declare any variables. Like:

>>>> enum X {A, B}

>>>> static void test(Object obj) {
>>>>   switch (obj) {
>>>>     case String _, X.B -> System.out.println("B or String");
>>>>     default -> System.out.println("other");
>>>>   }
>>>> }

>>>> public static void main(String[] args) {
>>>>   Test.test("ddd");
>>>>   Test.test(X.B);
>>>> }

>>>> Currently, such a code is not supported. Or will it be considered in
>>>> future JEPs?

>>>> With best regards,
>>>> Tagir Valeev.

>>>> On Mon, Sep 25, 2023 at 6:25 PM Mark Reinhold [ mailto:mark.reinhold at oracle.com
>>>> | <mark.reinhold at oracle.com> ] wrote:

>>>>> [ https://openjdk.org/jeps/456 | https://openjdk.org/jeps/456 ] Summary: Enhance
>>>>> the Java language with unnamed variables, which
>>>>>   can be initialized but not used, and unnamed patterns, which match a
>>>>>   record component without stating the component's name or type. Both are
>>>>>   denoted by an underscore character, _.

>>>>> - Mark

> --
> C.BOUDEREAU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230927/9df48d37/attachment-0001.htm>


More information about the amber-dev mailing list