SonarQube: Community Build v25.7.0.110598
Java: 21
Eclipse: 2025-09
Hey, there are some problems with the Java Rule S6205, which made me deactivate the rule. It looks like there’re two or three rules in one with confusing descriptions and unsufficient implementation.
The code, that I came from can be stripped down to this:
public void foo()
{
switch ( "x" )
{
case "y" ->
{ // FP
throw new NotImplementedException( "1" );
}
case "z" ->
{ // FP
throw new NotImplementedException( "2" );
}
default ->
{
//
}
}
}
The rule complains about “Remove redundant block”. This message led me in the wrong direction. I thought, the rule was ignoring, that the two blocks are not equal in the exception message. Actually it wanted me to remove the curly braces there, because the case only contains a one-liner. While I consider this valid style and don’t want a rule to force me to remove these curly braces, if there are other braced blocks in the same construct (same in an if, where then is braced and else is not, which I consider ugly, though of course kind of unnecessary) I do see the point here.
At the same time the rule is acutally looking for redundant keywords especially yield. The rule’s short description also tells us that and nothing about redundant block braces. The complete switch, which I stripped down here, contained some other cases, where return was used instead of yield.
And this led me to the conclusion, that the whole rule should be reimplemented and split up into three rules.
- The first one looks for redundant curly braces in the switch (or maybe more general). If you ask me, curly braces are not to be considered redundant, if other blocks on the same level are braced (as mentioned above). But the rule could also be very strict and nag about every single redundant brace, which would make me deactivate it of course.
- The second rule would look for correct use of keywords in a switch/case. It should even go a little further. If a switch is used with arrow notation, no returns should be used, because they can be confusing as they could make you expect the value to also be passed to the method return and quit the method. As I understand it, that’s what yield was created for. So while it is accepted by the compiler to use return in an arrowed switch, it should be avoided and treated as bad habit.
- The third rule would apply the rundancy check for break/yield in an arrowed switch.
I hope, this was not explained in a too complicated way. Do you need more info? What do you think?