[jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v3]

[Maurizio Cimadamore]

On Fri, 18 Jun 2021 13:23:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating javadoc, code and tests as suggested.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 175:

> 173:      * Bootstrap method for linking an {@code invokedynamic} call site that
> 174:      * implements a {@code switch} on a target of an enum type.  The static
> 175:      * arguments are an array of case labels which must be non-null and of type

This sentence can still be improved and made cleared. Example:

> The static arguments are used to encode the case labels associated to the `switch` construct, where each label can be encoded as a `String` (e.g. to represent an enum constant), or, alternatively, as a `Class` (e.g. to represent a type test pattern whose type is an enum type).

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 179:

> 177:      * <p>
> 178:      * The returned {@code CallSite}'s method handle will have
> 179:      * a return type of {@code int} and accepts two parameters: the first argument

By writing the javadoc text above, it came to mind that, perhaps, some validation is in order for the static arguments. For instance:

* the enum type of a Class parameter doesn't match that of the BSM
* the static arguments contain more than one Class parameter (I think even if they are all of the same "correct" type, that's bogus, right?)

-------------

PR: https://git.openjdk.java.net/jdk17/pull/81