Since Java 17 we can use `case Foo ->` instead of `case Foo:`, which has several advantages regarding variable scopes and fall-through handling. For more details cf. !100. Many cases of old-style switch statements have been refactored already, for example in !252. The remaining cases are those where Google Error Prone does not suggest an automated refactoring, which seems to be mostly for cases with intended fall through (`// $FALL-THROUGH$`), fall through of an empty case into `default:` (which is not possible in the new syntax and sometimes needs code duplication), and some nested switch statements. I count 33 Java files with a classic case label in CPAchecker right now, out of which 12 have `// $FALL-THROUGH$`. So it would be doable to clean them all up manually and potentially get rid of classic case labels completely. - [x] Check all cases of `// $FALL-THROUGH$` whether the code can be rewritten nicely without the fall through. One potential solution could be to move code into utility methods and only duplicate the calls to these methods. - [x] Rewrite all other classic case labels. Sometimes we can also easily rewrite the code into a form that Error Prone can refactor (example: 98c0ca6ca87aa9b7a6980196e38277dcb00068a5). Here we should also check whether we can further improve the code at the same time and convert the switch statement to a switch expression, which has more advantages (example: c5800138a77fa85dd4e0a15b4a35677b1f2528f4). - [x] Add CI check that forbids classic case labels. - [x] Check whether we can get rid of more `default` cases in switch expressions. The more we delete the better the compiler can help us if we add an entry to the enum that is used in a switch (example: c5800138a77fa85dd4e0a15b4a35677b1f2528f4). Hopefully we can also automate this.