The order of pattern labels is imposed by the class hierarchy and is quite strict, but we can do some changes without creating any dominance issues. For instance, since Extra and Large are subclasses of Medium, we can switch their positions. Some things apply to Jumbo and Huge since they are both subclasses of Medium via Extra, respectively Large.In this context, the compiler evaluates the selection expression by trying to match it against this hierarchy via an IS-A inheritance relationship. For instance, let’s order a Jumbo drink while there are no more Jumbo and Extra drinks:
return switch(o) {
case Huge h: yield “We can give a Huge …”;
case Large l: yield “We can give a Large …”;
case Medium m: yield “We can give a Medium …”;
case Small s: yield “We can give a Small …”;
default: yield “Sorry, we don’t have this drink!”;
};
If we order a Jumbo (o is Jumbo) then we will get a Medium. Why? The compiler matches Jumbo against Huge without success. The same result is obtained while matching Jumbo against Large. However, when it matches Jumbo against Medium it sees that Jumbo is a Medium subclass via the Extra class. So, since Jumbo is a Medium, the compiler chooses the Medium m pattern label. At this point, Medium matches Jumbo, Extra, and Medium. So, soon will remain out of Medium as well:
return switch(o) {
case Huge h: yield “We can give a Huge …”;
case Large l: yield “We can give a Large …”;
case Small s: yield “We can give a Small …”;
default: yield “Sorry, we don’t have this drink!”;
};This time, any request for Jumbo, Extra, Medium, or Small will give us a Small. I think you got the idea.Let’s make a step further, and let’s analyze this code:
private static int oneHundredDividedBy(Integer value) {
return switch(value) {
case Integer i -> 100/i;
case 0 -> 0;
};
}
Have you spotted the problem? A pattern label case dominates a constant label case, so the compiler will complain about the fact the second case (case 0) is dominated by the first case. This is normal, since 0 is an Integer as well, so it will match the pattern label. The solution requires switching the cases:
return switch(value) {
case 0 -> 0;
case Integer i -> 100/i;
};
Here is another case to enforce this type of dominance:
enum Hero { CAPTAIN_AMERICA, IRON_MAN, HULK }
private static String callMyMarvelHero(Hero hero) {
return switch(hero) {
case Hero h -> “Calling ” + h;
case HULK -> “Sorry, we cannot call this guy!”;
};
}
In this case, the constant is HULK and it is dominated by the Hero h pattern label case. This is normal, since HULK is also a Marvel hero, so Hero h will match all Marvel heroes including HULK. Again, the fix relies on switching the cases:
return switch(hero) {
case HULK -> “Sorry, we cannot call this guy!”;
case Hero h -> “Calling ” + h;
};
Ok, finally, let’s tackle this snippet of code:
private static int oneHundredDividedByPositive(Integer value){
return switch(value) {
case Integer i when i > 0 -> 100/i;
case 0 -> 0;
case Integer i -> (-1) * 100/i;
};
}
You may think that if we enforce the Integer i pattern label with a condition that forces i to be strictly positive then the constant label will not be dominated. But, this is not true; a guarded pattern label still dominates a constant label. The proper order places first the constant labels, followed by guarded pattern labels, and finally, by non-guarded pattern labels. The next code fixes the previous one:
return switch(value) {
case 0 -> 0;
case Integer i when i > 0 -> 100/i;
case Integer i -> (-1) * 100/i;
};
Ok, I think you got the idea. Feel free to practice all these examples in the bundled code.