JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview)

Remi Forax forax at
Tue Jun 1 20:39:40 UTC 2021

----- Mail original -----
> De: "Mike Rettig" <mike.rettig at>
> À: "Brian Goetz" <brian.goetz at>
> Cc: "mark reinhold" <mark.reinhold at>, "jdk-dev" <jdk-dev at>
> Envoyé: Mardi 1 Juin 2021 22:32:15
> Objet: Re: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview)

> On Tue, Jun 1, 2021 at 2:33 PM Brian Goetz <brian.goetz at> wrote:
>> We try very hard to stay away from this technique, for several reasons.
>> First, the language *has* a definition; compilers should, in general,
>> implement that, not second-guess it.  And second, it doesn't scale; the
>> endgame of that approach is that we end up with an ever-growing set of
>> flags (possibly interacting!) for enforcing the top 10,000 most popular
>> coding styles.  This is something better handled by IDEs or static analysis
>> tools, where you can configure them to bark on the patterns you find
>> problematic.
>> But, you do have the option of using -Werror, which offers zero-tolerance
>> for warnings, and then can turn on the lint warning categories of your
>> choice.
> Is this a style issue or a legacy code issue? Given that sealed types are
> being introduced with completeness, then it has to be a legacy code issue.
> With jigsaw, warnings were introduced to identify problematic code. These
> warnings later became errors.  I hope the same treatment can be given to
> incomplete switches.

It's the difference between an API point like setAccessible for jigsaw and a language construct, the statement switch,
language constructs are forever not APIs.

> Mike


More information about the jdk-dev mailing list