I don't like Fintan's Vector solution much either, but I disagree with Peter's reasons:
1) Your switch statement is dependent on the order of the vector which means if someone as SUN changes the implementation and the order isn't maintain, then this will be one really hard bug to find. Eh? How could Sun change the implementation without violating the API? Vector has always gauranteed that it maintained the order of its elements.
2) You solution requires creating an extra Vector object which I don't think is needed. True, but not that big a deal. The object could be declared and initialized in a static initializer to minimize overhead. (Though admittedly this will further reduce readability.)
3) You solution doesn't handle mix-cases in the comparision. Easy enough to modify it to convert everything toLowerCase() before comparison, if you want to ignore case. This can be done in the standard idiom as well (if/else if) - it will be slightly faster than using equalsIgnoreCase() in every if. However, if you need to ignore case for some elements, but not others, then this won't work. And it
is less clear than writing equalsIgnoreCase() wherever that effect is desired.
For me, the one big reason to avoid the vector technique is that the
programmer(s) must maintain the relationship between the order of elements in the Vector, and the values in the case statements. Imagine what happens if you have, say, 50 different strings listed, and then later you need to modify the code to remove one of the Strings at the beginning. It's easy to delete the v.addElement("First String") and the corresponding case - but then you must also change each of the subsequent case labels too. And what if the code is edited by a co-worker who doesn't realize just how the structure operates? If he introduces an error into the case statements, it will be hard to spot without checking the whole case structure carefully. This idiom is a maintenance nightmare. (Which Peter
did say - I just disagree with the further explanation.)
Also, it's worth noting that internally, the indexOf() method is just going to loop through all the elements and perform an equals() comparison until it finds a match. So indexOf() will be slightly slower than the if/else if structure since it also does the extra work of maintaining a loop index and accessing Vector elements. The switch statement may be fast - but the code before it is not.
