JEP 325 switch needs to be paused to address developers' needs

[Ryan Schmitt]

Please see [1], as an excellent summary of all of the copious amounts of
discussion and thought that have gone into this feature over the last few
years. If you just found out about this feature earlier today, you should
probably assume that you don't have a very solid grasp of the design space
yet, and that "minimal effort" changes have been considered and ruled out.

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001861.html

On Mon, Oct 15, 2018 at 10:56 AM Fred Toussi <fredt at users.sourceforge.net>
wrote:

> short version:
> JEP 325 needs to be paused. Its present form does not address the issues
> with switch as far as existing, currently maintained code is concerned. It
> also makes new code looks very different from what we are used to. An
> alternative solution is possible and can be introduced with minimal effort.
>
> longer version:
> I maintain the HSQLDB project which has thousands of lines in switch
> statements. I learned about JEP 325 only today when it was mentioned in an
> email promoting the latest JDK early access build.
>
> In traditional switch, there are two issues that need to be fixed, namely
> the silent fall-through and the scope of variables declared within the
> switch statement.
>
> The proposed JEP 325 attempts to fix the issues (and also allow the switch
> to act as an expression) but it does so by changing the colon token used
> inside the switch block to the comma and arrow .
>
> This change of the tokens means:
>
> (1) Existing application code that could benefit from fixing the original
> issues (for the code to be further maintained and changed in the future)
> has to be heavily edited, which makes it prone to new errors being
> introduced.
> (2) Visual disharmony between the look of the new code and the traditional
> switch that developers have been used to for decades.
>
> I would like to propose to hold this JEP and change it to keep the colon
> in order to ease introduction of the new feature into existing application
> code bases.
>
> There is an alternative option, namely adding a qualifier to the keyword
> "switch" to distinguish the new syntax. I would suggest to add the keyword
> "new" to the new usage of  "switch". If an alternative qualifier looks more
> appropriate, then that is fine too.
>
> The JEP can then be modified to keep the original colon, instead of
> replacing it with the comma and the arrow. The "break" without value or
> label will be disallowed.
>
> Existing code needs to be modified only to avoid the silent fall-through
> switch cases and to remove the redundant "break" keywords.
>
> My proposed use of "new" is not counter-intuitive, as we can use both "int
> myVar = new Myclass(arg);" and simply  "new Myclass(arg) ;" in Java.
>
> Fred Toussi
> Maintainer, HSQLDB Project
>
> Below are the examples given in the JEP text, written with the proposed
> qualified switch keyword.
>
> new switch (day) {
>     case MONDAY:
>     case TUESDAY:
>         int temp = ...
>         soSomething(temp);
>     case WEDNESDAY:
>     case THURSDAY:
>         int temp = ...     // We can call this temp
>         soSomething(temp);
>     default:
>         int temp = ...     // We can call this temp
>         soSomething(temp);
> }
>
> new switch (day) {
>     case MONDAY: FRIDAY: SUNDAY: System.out.println(6);
>     case TUESDAY:                System.out.println(7);
>     case THURSDAY: SATURDAY:     System.out.println(8);
>     case WEDNESDAY:              System.out.println(9);
> }
>
> // no default needed for fully covered enum
> int numLetters = new switch (day) {
>     case MONDAY, FRIDAY, SUNDAY : 6;
>     case TUESDAY                : 7;
>     case THURSDAY, SATURDAY     : 8;
>     case WEDNESDAY              : 9;
> };
>
> static void howMany(int k) {
>     new switch (k) {
>         case 1 : System.out.println("one");
>         case 2 : System.out.println("two");
>         case 3 : System.out.println("many");
>     }
> }
>
> int j = new switch (day) {
>     case MONDAY  : 0;
>     case TUESDAY : 1;
>     default      : {
>         int k = day.toString().length();
>         int result = f(k);
>         break result;
>     }
> };
>
>
>
>
>