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

[Fred Toussi]

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;
    }
};