JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview)
forax at univ-mlv.fr
Tue Jun 1 20:39:40 UTC 2021
----- Mail original -----
> De: "Mike Rettig" <mike.rettig at gmail.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "mark reinhold" <mark.reinhold at oracle.com>, "jdk-dev" <jdk-dev at openjdk.java.net>
> 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 oracle.com> 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
>> 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
> 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.
More information about the jdk-dev