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

Mike Rettig mike.rettig at
Tue Jun 1 20:32:15 UTC 2021

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.


More information about the jdk-dev mailing list