On Wed, 19 Apr 2023 16:45:06 GMT, Vicente Romero <[email protected]> wrote:
>> Jan Lahoda has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Fixing infinite loop where a binding pattern is replaced with a binding
>> pattern for the same type.
>> - Reflecting review comments.
>> - Fixing exhaustiveness for unsealed supertype pattern.
>> - No need to enable features after error reported.
>> - SwitchBootstraps.typeSwitch should not initialize enum classes.
>> - A prototype of avoiding enum initialization.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 279:
>
>> 277: }
>> 278:
>> 279: private static int lazyDoEnumSwitch(Enum<?> target, int startIndex,
>> Object[] labels, MethodHandles.Lookup lookup, Class<?> enumClass,
>> MutableCallSite callSite) throws Throwable {
>
> can `doEnumSwitch` be folded into `lazyDoEnumSwitch`? just a suggestion, I'm
> OK with either way just that now it is not clear that we need two methods
> here. Also in `doEnumSwitch` and out of curiosity what example of user code
> could hit this section:
>
>
> if (label instanceof Class<?> c) {
> if (c.isAssignableFrom(targetClass))
> return i;
> }
>
> EDIT: nvm I found one example
The intent here is to avoid eager initialization of enums - so, until the enum
is initialized, `lazyDoEnumSwitch` will be used (which, by itself, won't
compute any results, except the result for `null`), which is then replaced with
`doEnumSwitch` using the enum constants directly.
The enum switches support patterns as well, so something like:
enum E {A;}
E e = ...;
switch (e) {
case E ee -> {}
}
is valid, and should trigger the part with Class labels.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1172623143
