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

Ben Evans benjamin.john.evans at gmail.com
Thu Aug 23 15:58:29 UTC 2018

I tend to agree with Stephen. In particular, as Brian has so correctly pointed out, most Java developers over-focus on syntax.

Therefore, it seems likely that, despite marking a syntax-introducing feature as Preview, early adopters will come to rely on it, and even put code that uses it into production. This then raises the barrier to change the syntax of the Preview Feature. This seems to me to be more pronounced in the case of core language features, as opposed to incubator libraries and modules (e.g. the HTTP client).

I also want to ask about the balance we're striking between existing Java developers and newcomers. I would argue that existing Java developers really don't care whether we have a new keyword ('match') for an expression form providing equivalent functionality to a switch statement - existing code needs to be refactored in either case to take advantage of the new capability.

On the other hand, I've also been spending a lot of time teaching newcomers to the Java lanaguage over the last year. Given how my students have struggled with default fallthrough, I can't see how introducing a syntax form where the fallthrough behaviour depends upon a minor syntax variation of the switch label is anything other than a compounding of the original sin of importing default fallthrough from C/C++. A separate keyword makes it entirely clear that this is a different language feature and so different behaviour is to be expected.

I like this version of the proposal better than previous discussions, but I'm sure in my own mind that as proposed it will be a source of new bugs that could be avoided. By introducing a new keyword we can maintain a clean split between the legacy switch and a syntax that can be cleanly upgraded to full match expressions over subsequent Java versions (which is actually a much better fit, to my mind, to the Preview Feature mechanism).

Thanks,

Ben On Thu, 23 Aug 2018 at 08:18, Stephen Colebourne <scolebourne at joda.org> wrote:

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

More information about the jdk-dev mailing list