On Fri, 18 Jun 2021 13:23:57 GMT, Jan Lahoda <[email protected]> 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
