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

[Fred Toussi]

Please read the last paragraph of the summary you linked to.

"The preview mechanism will allow us to gather feedback on the feature 
from actual use, rather than theorizing from no examples, and 
potentially adjust the specification before final release if warranted.  
So if any _new_ issues up come as a result of actual experience, we are 
happy to hear about them."

I am talking about actual use in large existing, evolving code bases. 

It would be good for new features of Java to be easily applied to existing code. This feature can simplify a huge amount of existing code but only if it can be applied very easily. That's one of the motivation for my request. Obviously, I'm not proposing to "fix" the mistakes of the past as discussed in the text. The traditional switch form will still be supported exactly as it is now.

The use of fall-through was probably an acceptable feature in the days when very compact code was needed for applets or embedded programs. That level of compactness is no longer required and each fall-through can be avoided at the expense of a couple of lines of extra code in applications.

The minimal effort I mentioned applies both to the change in the specification and the application of the new feature to existing code bases. 

Regarding the specification, the change I propose does not alter the proposed semantics. It requires only small changes at the parsing stage.

Also, looking again at the example, the "new" keyword is not even needed when the switch is an expression.

Fred Toussi

On Mon, Oct 15, 2018, at 20:25, Ryan Schmitt wrote:
> 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;
> >     }
> > };
> >
> >
> >
> >
> >