Extend switch .. case statement for Object types and simple expressions (original) (raw)

Ulf Zibis Ulf.Zibis at gmx.de
Mon Mar 30 11:31:02 PDT 2009

AUTHOR(S): Ulf Zibis, Cologne, Germany

OVERVIEW FEATURE SUMMARY: Extend switch .. case statement for Object types and simple expressions. MAJOR ADVANTAGE:

EXAMPLES SIMPLE EXAMPLE: (1): switch( myObject) { case CONSTANT1 : doSomething(); break; case CONSTANT2 : doSomethingElse(); break; default : doSomethingDefault(); } (2): switch( myString) { case equals("red") : stop(); break; case equals("green") : go(); break; default : openYourEyesForCrossingTraffic(); } (3): switch( myString) { case equalsIgnoreCase("RED") : sureStop(); break; case equalsIgnoreCase("GREEN") : sureGo(); break; default : beAwareOfPoliceWachtingYou(); }

ADVANCED EXAMPLE: (1): switch( primitiveInt) { case == 10 : doOnlyIf10(); // alternative syntax for 'case 10:' case < 10 : case >= 20 : break; default : doOnlyInRange(); } (2): switch( primitiveInt) { case (>= 10 && < 20) : doOnlyInRange(); default : throw new Exception("Out of range"); } (3): switch( myString) { case contains("foo") : doSomething(); break; case regionMatches(true, 2, otherString, 4, 6) : doSomethingElse(); break; default : doSomethingDefault(); } (4): switch( myString.equals()) { // alternative: myString.equals(..) case "foo" : foo(); break; case "bar" : bar(); break; default : dontCare(); } (5): switch( className.startsWith("String", ..)) { // alternative: className.startsWith("String", ?) case 0 : doForSimpleName(); break; case 9 : doForFullName(); break; default : canNotDecide(); } (6): switch( anyObjectOrPrimitive instanceof) { // note, that casting is solved implicit case boolean, byte, ... float : break; // Don't do anything case double : forDouble(anyObjectOrPrimitive); case HashMap : case TreeMap : forPlattformMap(anyObjectOrPrimitive); break; case Map : forOtherMap(anyObjectOrPrimitive); break; default : forObject(anyObjectOrPrimitive); } (7): switch( some_lethargic_function_we_cant_call_much().equals(..) ) { case "this": case "that": this_or_that(); break; case "bigjump": big(); // fall case "jump": jump(); break; case "secondlastchance": case "lastchance": last_chance(); break; default: do_default(); } .. as replacement for: String sSomeString = some_lethargic_function_we_cant_call_much(); if( sSomeString.equals( "this" ) || sSomeString.equals( "that" ) ) this_or_that(); else if( sSomeString.equals( "jump" ) || sSomeString.equals( "bigjump" ) ) { if( sSomeString.equals( "bigjump" ) ) big(); jump(); } else if( sSomeString.equals( "secondlastchance" ) || sSomeString.equals( "lastchance" ) ) { last_chance(); } else do_default();

ALTERNATIVES: switch( myString) { // note the '.', I personally would prefer this alternative! case .equals("red") : stop(); break; case .equals("green") : go(); break; default : openYourEyesForCrossingTraffic(); } switch( primitiveInt) { // note the '.' case (. >= 10 && . < 20) : doOnlyInRange(); // case (? >= 10 && ? < 20) : doOnlyInRange(); // alternative default : throw new Exception("Out of range"); }

DETAILS SPECIFICATION: The new syntax should be interpreted as switch ( leftExpressionPart ) { case rightExpressionPart1 : case rightExpressionPart2 : ... default : } The result of entire expression should be boolean type. There is shortcut for: leftExpressionPart: intVariable rightExpressionPart: == intLiteral (the '==' could be ommitted.)

COMPILATION: Compiler could first pre-compile to appropriate if..then..else syntax. Bytecode would not be affected, but in special cases it could be more compact, if noted pre-compilation would be replaced by sophisticated optimization. TESTING: Compiler byte-code results for new syntax should be same than from equivalent hand-coded legacy if..then..else syntax . Exception: sophisticated optimization. LIBRARY SUPPORT: No supporting libraries are needed for the feature? REFLECTIVE APIS: There should not be any affection to reflection API. OTHER CHANGES: No. MIGRATION: No refactoring is needed to stay compatible.

COMPATIBILITY BREAKING CHANGES: No previously valid programs are now invalid. ... but ATTENTION: If proposals from some other guys regarding "Strings in switch" would be taken into JDK 7, there won't be any compatible way to implement my more general proposal in future version of JDK !!! --> So switch .. case statement should compare for IDENTITY if not syntactically determined otherwise. --> compare for EQUALITY would also break semantic of existing switch .. case statement. EXISTING PROGRAMS: Source and class files of earlier platform versions interact with the feature without any notice.

REFERENCES http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000001.html http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000213.html http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.html http://forums.java.net/jive/thread.jspa?messageID=27781&#27781 http://forums.java.net/jive/thread.jspa?messageID=15769&#15769 http://forums.java.net/jive/thread.jspa?messageID=27773&#27773 http://forums.java.net/jive/thread.jspa?messageID=11393&#11393 EXISTING BUGS: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5012262 URL FOR PROTOTYPE (optional):

More information about the coin-dev mailing list