RFR: 8366968: Exhaustive switch expression rejected by for not covering all possible values [v4]

Aggelos Biboudis abimpoudis at openjdk.org
Wed Oct 22 10:45:05 UTC 2025


On Wed, 22 Oct 2025 10:34:36 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - Merge branch 'master' into JDK-8366968
>>  - Merge branch 'JDK-8367499-2' into JDK-8366968-2
>>  - Cleanup.
>>  - Cleanup.
>>  - Cleanup.
>>  - Merge branch 'JDK-8367499-2' into JDK-8366968-2
>>  - 8367499: Refactor exhaustiveness computation from Flow into a separate class
>>  - Removing trailing whitespace.
>>  - There are no relevant permitted subtypes of a non-abstract class, not even the class itself.
>>  - 8366968: Exhaustive switch expression rejected by for not covering all possible values
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/ea7186a8...f75a6830
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 240:
> 
>> 238:                                     currentSubTypes =
>> 239:                                             permitted.stream()
>> 240:                                                      .filter(perm -> types.isSubtype(types.erasure(perm.type),
> 
> Can we also add a test with a generic hierarchy to witness the alternative path in the `types.erasure` part? I am sure the following would pass thought so feel free to ignore:
> 
> 
> class SomeType {}
> sealed interface Base<T extends SomeType> permits Special, Value {}
> non-sealed interface Value<T extends SomeType>  extends Base<T> {}
> sealed interface Special<T extends SomeType> extends Base<T> permits SpecialValue {}
> non-sealed interface SpecialValue<T extends SomeType> extends Value<T>, Special<T> {}
> 
> static <T extends SomeType> int demo(final Base<T> base) {
>     return switch (base) {  
>          case Value<T> value -> 0;
>     };
> }

Also, since this area of the `if` tries to detect the diamond shape does it make sense to extract it into a method so that it stands out? Otherwise a comment would be excellent here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27547#discussion_r2451584240


More information about the compiler-dev mailing list