JEP proposed to target JDK 12: 325: Switch Expressions (Preview)

[Stephen Colebourne]

As I have expressed previously on amber-dev, I find the design adopted
here to be overly complex and with a poor syntax choice. There are
aspects to like, and the proposal is better than earlier versions. I
also acknowledge that this is a proposal to create a preview language
feature, however in all likelihood, there will be no further changes
to the syntax/design once integrated as a preview.

Some specific objections:

(FYI, "classic" uses colon and has fallthrough-by-default, "enhanced"
uses arrow -> and does not allow fall-through).

- the original goal was to add one new language feature (expression
switch), yet the solution adds three (classic expression switch,
enhanced statement switch & enhanced expression switch). This
unnecessarily complicates Java for little gain IMO.

- all the evidence I've seen suggests that fallback in switch is very
rare, and I'd strongly argue that most developers consider
fallthrough-by-default to be a poor feature of Java. Adding a new
language feature (classic expression switch) which adds more
fallthrough-by-default is a mistake IMO. It is likely that style
guides and best practice will recommend against using classic
expression switch. I do not accept that consistency ("it makes a 2x2
grid") is a sufficient reason to add a new language feature that will
effectively be dead on arrival.

- the use of -> as the separator in enhanced switch is undesirable
IMO. Objections to the syntax have also been made by some expert group
members. The particular problem is that it means something different
to the use of -> in lambda expressions. This can result in confusing
semi-puzzlers, such as "case RED -> YELLOW -> 6";.

- the vast majority of existing switch statements would be more safely
expressed using the enhanced form. As such, the enhanced form
effectively replaces the classic form in Java - its that much better
that classic statement switch will just be abandoned by developers
IMO. Given this and the pointlessness of adding classic expression
switch, the argument for using the keyword `switch` for the enhanced
forms is weak IMO. At my presentations on the topic, the vast majority
of developers have come to the conclusion that the enhanced form
should use a different keyword, for example `match`, not `switch`.
Doing so allows the colon to be used instead of the arrow:

var name = match (trafficLight) {
  case RED: "Red";
  case YELLOW: "Yellow";
  case GREEN: "Green";
};

- Adding a new keyword/symbol for the expression form (and potentially
declaring it an ExpressionStatement instead of having a separate
statement form) would IMO be a simpler approach to the problem space,
potentially adding just 1 new form rather than 3 as proposed by the
JEP.


In summary, the world will not end if the JEP 325 progresses, and this
proposal is much better than previous ones. However I believe that by
taking the route of expanding `switch` rather than using a different
keyword/symbol the result has been greater complexity than is
necessary to meet the actual goal of "expression switch".

thanks
Stephen


On 17 August 2018 at 18:44,  <mark.reinhold at oracle.com> wrote:
> The following JEP is proposed to target JDK 12:
>
>   325: Switch Expressions (Preview)
>        http://openjdk.java.net/jeps/325
>
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Friday,
> 24 August, or if they’re raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I’ll target this JEP to JDK 12.
>
> - Mark
>
>
> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html