switch statement with Object

[Nitesh Sawant]

Java 7 has new feature : "switch statement with java.lang.String".
What may be the reason for not adding feature as "switch statement with java.lang.Object" ?

[Nam Ha Minh]

Nitesh Sawant wrote:Java 7 has new feature : "switch statement with java.lang.String".
What may be the reason for not adding feature as "switch statement with java.lang.Object" ?

To check for what from the object?

[Campbell Ritchie]

An Object as a switch case is too non‑specific. What people wanted was an alternative to

if (name.equals("Campbell"))
{
 // ...
}
else if (name.equals("Ritchie"));
{
 // ...
}
else if (name.equals("Nitesh"))
{
 // ...
}
else if (name.equals("Sawant"))
{
 // ...
}
else
{
 // ...
}

The switch on Strings was specifically requested by users. There was probably no demand for switching on plain simple Objects. It is worth comparing the bytecode of this sort of code:

public enum Direction
{
   NORTH, SOUTH, EAST, WEST;
}

// Example 1
switch (direction)
{
   case 90: //east
      // ...
      break;

   case 180: //south
      // ...
      break;

   case 0: case 360: // North. Fall-through intended
      // ...
      break;

   case 270: //west
      // ...
      break;

   default:
      // ...
      break;
}

// example 2:
switch (direction)
{
   case Direction.EAST:
      // ...
      break;

   case Direction.SOUTH:
      // ...
      break;

   case Direction.NORTH:
      // ...
      break;

   case Direction.WEST:
      // ...
      break;

   default:
      // ...
      break;
}

// example 3:
switch (direction) /* Fall-through intended in four places */
{
   case "EAST": case "east":
      // ...
      break;

   case "SOUTH": case "south":
      // ...
      break;

   case "NORTH": case "north":
      // ...
      break;

   case "WEST": case "west":
      // ...
      break;

   default:
      // ...
      break;
}

Now look how much more complicated the bytecode is for Strings. It would be even worse for any kind of Object. But see how much easier the original code is to read with enum elements or Strings.

[Henry Wong]

Also, let's not forget that Java requires that the targets for the case statements must be compile time constants. And Java already have it well defined for strings. To switch on anything else, a new concept of object literals will have to be created.

Henry

[Mike Simmons]

Henry Wong wrote:Also, let's not forget that Java requires that the targets for the case statements must be compile time constants.

Or enums.

Henry Wong wrote:And Java already have it well defined for strings. To switch on anything else, a new concept of object literals will have to be created.

Or they could just change the rules, as they did when they added enums.

It wouldn't really be difficult to make rules for an Object switch statement that was equivalent to a series of if/else statements. If they wanted to. But there also wouldn't be much point, since such an addition wouldn't really be any better than a series of if/else statements.

[Praveen Kumar M K]

In my opinion(maybe a bit naive here), they probably did not go for Object switch because then they would have to get into instanceof or getClass confusions. It would raise more issues in case there was a situation of Superclass and Subclass cases in the same switch statement(which would potentially violate the IS-A releation).

[Campbell Ritchie]

Can you still find the JSR about that? It may be that people specifically requested switch on Strings (I am pretty sure that is in fact the case) and did not request switch on anything else.

[Winston Gutkowski]

Mike Simmons wrote:It wouldn't really be difficult to make rules for an Object switch statement that was equivalent to a series of if/else statements.
If they wanted to.

Hmmm. Not so sure about that; and it would mean re-writing practically all the docs about switch, since right now it uses compile-time constants.
A switchref command perhaps?

But there also wouldn't be much point, since such an addition wouldn't really be any better than a series of if/else statements.

Again, probably a personal preference, but I really like the "look" of switch statements. To me they're visually very clean.

Winston

[Henry Wong]

Mike Simmons wrote:

Henry Wong wrote:Also, let's not forget that Java requires that the targets for the case statements must be compile time constants.

Or enums.

Henry Wong wrote:And Java already have it well defined for strings. To switch on anything else, a new concept of object literals will have to be created.

Or they could just change the rules, as they did when they added enums.

Although, enums are not compile time constants -- as defined by the specification. The possible values of the enum are constants, and can be determined at compile time -- so I guess it is possible to use this same technique to switch on the wrapper objects as well.

Winston Gutkowski wrote:

But there also wouldn't be much point, since such an addition wouldn't really be any better than a series of if/else statements.

Again, probably a personal preference, but I really like the "look" of switch statements. To me they're visually very clean.

Not sure if I agree with this -- when I see a switch statement, I expect a constant dispatch (or almost constant dispatch) .... meaning I don't expect the 1000th case statement to have to go through 1000 condition checks before it can be located.

Henry

[Martin Vashko]

Henry Wong wrote:... I don't expect the 1000th case statement ...

Well, I'm pretty liberal when it comes to adhering to OO design principles, but a switch with thousand cases would make me to start some serious refactoring code-rewriting effort.

[Winston Gutkowski]

Henry Wong wrote:Although, enums are not compile time constants -- as defined by the specification. The possible values of the enum are constants, and can be determined at compile time -- so I guess it is possible to use this same technique to switch on the wrapper objects as well.

I have to admit, I haven't thought this through completely, but it seems to me that the definition for switch could be extended to include references, providing it's clearly understood that a case statement involving a reference is only satisfied by an identity comparison.

That way, it would allow enum values perforce, and also String literal matching via:
switch (s.intern()) { ...
Indeed, I reckon the compiler could probably substitute it automatically for String expressions.

It would also then work for classes, viz:

switch(someClass) {
   case int.class:
      // whatever
   case String.class:
      // whatever
   ...
}

although I'm not really sure if we want to be encouraging dispatch code.

Winston