As stated in the other answers, the fallthrough feature of the switch statement in Java language is what you are looking for (the removal of the brackets sould be applied too):
switch (name) {
case text1:
case text4:
doActionOne();
break;
case text2:
doActionTwo();
break;
case text3:
doActionThree();
break;
}
But, while this solution answers your immediate question, I think it's important to highlight that the question itself should be widened to include alternative solutions, preferably to the usage of a switch statement and definitely considered as Best Practices in Object Oriented Programming.
Switch and If statements should be avoided when possible. They will limit the Readability, Reusability, Replaceability, Testability and Maintainability of your code. All this reasons led to the birth of initiatives like the Anti-If-Campaign; you should not stop using ifs and switches at all, but it would be better to delegate them to perform trivial tasks only; complex tasks like your could be engineered in several ways;
While Switch statements could be exploited in the C language to perform the loop unrolling technique and optimize the program's execution speed (like in the Duff's device mentioned by an commenter of your question), it would not be possible to speed up Java code that way. All the sacrifices of point n.1 will not lead to any benefit even by the virtual machine point of view... just to be sure it is clear.
Generally, the Polymorphism OOP feature should be used to achieve tasks like your; it would be better to have 100 different objects and instantiate the right one instead of having 100 hard coded switch's case statements (for all the reasons of point n.1). Each different behaviour would be coded in a single, self-contained place, they could be tested, maintained, reused in other parts of your projects, and you would be able to export a subset of this objects to another project without the needs to edit and refactor any code (the huge switch for example);
The entities used by your software could then be translated in objects like this:
public Interface Action {
public void doSomething();
}
public class ActionOne implements Action {
public void doSomething(){
System.out.println("doSomething One");
}
}
public class ActionTwo implements Action {
public void doSomething(){
System.out.println("doSomething Two");
}
}
public class ActionThree implements Action {
public void doSomething(){
System.out.println("doSomething Three");
}
}
For an even stricter usage, instead of different objects you could create an enum as "polymorphic anti-if agent", like described in this great answer by Robert C. Martin (one of the founding fathers of the Agile Software Development).
Since in your case, the conditions are not from, for example, a <select> (where each element of the Select List could have been translated to a different object in Java, like described above), but from a free inputable <input type="text">, for this specific case, I think that a nice solution would be the following: use an HashMap with multiple keys pointing to the same objects.
on an initialization object:
// initialization (performed once)
HashMap<String,Action> map = new HashMap<String,Action>();
ActionOne actionOne = new ActionOne();
ActionTwo actionTwo = new ActionTwo();
ActionThree actionThree = new ActionThree();
map.put("text1", actionOne);
map.put("text2", actionTwo);
map.put("text3", actionThree);
map.put("text4", actionOne); /* <-- here you are referencing
the first object with a new key */
on one (of n) object(s) where you perform the business
// usage ("parsing")
String userInput = request.getParameter("userInput");
if (map.contains(userInput))
map.get(userInput).doSomething();
The last two lines could replace a huge switch statement, and they can be put in other 100 classes without rewriting your initialization object (that would be in a reusable class apart), nor any single Action object's business logic, located inside each Action object.
And what about adding new objects (let's say ActionFour) ?
It would only need creating of the object itself and adding it in the initializazion class. No matters if the parsing from the input will be performed in 100 different classes, none of them would need to be touched at all.
Pretty cool uh ?
