Soliciting opinions on JDK-8219412

[Archie Cobbs]

Following up on this...

It looks to me like this is pretty much implemented already as part of the
JEP 433 "Pattern Matching for switch" preview feature.

It appears that TransPatterns.handleSwitch() would DTRT. Currently it's
only used if the switch has one or more patterns, but since it's written to
handle switches with a combination of patterns and constants, simply
feeding it a "traditional" enum switch should accomplish what we want.

So that makes this primarily a refactoring task, but one that should
probably wait until JEP 433 is out of preview.

-Archie

On Mon, Jan 9, 2023 at 10:20 AM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> Thanks for the comments. Using invokedynamic makes perfect sense! (and I'm
> disappointed I didn't think of it :)
>
> I'll take a look into it and report back.
>
> -Archie
>
> On Mon, Jan 9, 2023 at 9:54 AM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> I agree with Brian. If we want to fix this and put our hands in the enum
>> switch classification, I think the best use of our time would be to tweak
>> enum switches to adopt the superior indy-based classification approach,
>> which should be immune to the issue you present.
>>
>> Thanks
>> Maurizio
>> On 09/01/2023 15:35, Brian Goetz wrote:
>>
>> Another strategy is to use an `invokedynamic` as a switch classifier.  (I
>> believe there is even a bootstrap for this implemented somewhere.)
>>
>>
> --
> Archie L. Cobbs
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230110/33e4d3f2/attachment-0001.htm>