Collection Issue for Sonar problems

[MichaelsJP]

Problem description

Let's fix some sonar issues and upgrade the code to newer Java standards

• Replace generic type usages <?> and missing ones
• Map to Map<String, SomeType>
• SomeObject<?> to SomeObject
• Replace StringUtility with Strings
• Suppress Warnings
• Fix imports + Reformat
• Clean unused imports/extends/implements
• Migrate switch/case to new format
• Migrate small swith/case or without default to if structures
• Migrate Pattern Matching for "instanceof" operator should be used instead of simple "instanceof" + cast
• Migrate generic exceptions to dedicated ones
• Use define reused strings as constants
• Simplify redundant boolean literals java:S1125
• Fix wrong/redundant unittest class visilibities for Junit5+ tests java:S5786
• Pom Cleanup. -> Worth it?
• Exception classes should have final fields java:S1165
• Remove unnecessary casts java:S1905
• Merge If statements with the enclosing one java:S1066
• Replace with primitive types if possible
• Replace boilerplate null checks for Map.get with computeifabsent java:S3824
• Add private constructors to utiliy classes java:S1118
• Migrate switch to enhanced switch
• Declare vars on multiple linesjava:S1659
• Use collection classes rather then implementations of it java:S1319
• Fix naming conventions, e.g. java:S115 (Constants, Functions, Vars)
• String literals should not be duplicated java:S1192

Proposed solution

Fix it.

[sfendrich]

I would prefer to not address sonar issues through such a issue collection for the following reasons:

1. This is not the intended way to use sonar, which recommends to only address issues on code you modify anyway.
2. The number of sonar issues is a good indicator for how messy some code is beyond what sonar is able to report. By fixing issues just because sonar reports them, we loose this sensor.