Improve devonfw Java quality profile

[hohwille]

With issue #16 implemented by PR #56 we now automatically provide a standard devonfw Java quality profile to SonarQube.
This comes from here:https://github.com/devonfw/sonar-devon4j-plugin/blob/master/src/main/resources/com/devonfw/ide/sonarqube/common/rules/devon4j/devon4j.xml

We need feedback from projects if this is a suitable default.
Obviously you can have endless discussions about this, but everyone is invited to provide feedback and request for change if a rationale is given. Examples are

• we might miss out a cool new rule that you suggest to add by default telling what the rule archives and linking to details. The rule should not produce many false-positives if the suggested default severity is higher than info
• we might use a rule that is deprecated or otherwise replaced by a newer and better rule.
• we might include a rule with a too high or too low severity. Please explain in detail why you want to raise or lower the severity. Give examples whenever possible.

[hohwille]

My first feedback (read squid as synonym to java as the feedback was from an older installation and the new feature is not yet available):

• squid:S2699 (Add at least one assertion to this test case.) - This rule is creating issues of severity Blocker. While the goal and idea of the rule is valid its implementation is so naive and stupid that it is creating tons of false-positives and it is therefore inacceptable to have these as Blocker. It does not support soft-assertions. It does not support when a test method delegates to a reused check-method that does the actual assertions, etc. So in the end it is better to entirely disable this rule (or at least put it down to Info severity).
• squid:S3369 (Add "security-constraint" elements to this descriptor.) - This rule is checking if security-constraint element is present in a web.xml. As we are using spring-boot and esp. spring-security this is typically not done via web.xml so in most cases this is also a false-positive. However, as we suggest not to have a web.xml at all and as there is at maximum only one web.xml per project, the rule is still valid and projects can set this to false-positive or not-an-issue if they properly address the problem on other levels. Otherwise it is still good to point projects to the potential problem.
• squid:S2063 (Comparators should be "Serializable") - Java Serialization is about dead. Do not use JEE App servers that serialize your objects silently into a session storage. Use stateless servers after all. Use reasonable formats such as JSON for safe and secure data-exchange and never ever use serialization for external interfaces (HTTP Invoker, RMI, etc.). Then you can stop wasting your time with serialVersionUID.
• squid:S00121 (Missing curly brace.) - This is rule is valid after all and it really is bad code style to create if statements or the like without curly braces. However, I only see this with stupid equals methods generated by Eclipse. Is the serverity Critical then? Either we need to get our common tools fixed to avoid producing such nonsense, or we might consider lowering the severity (to Minor or at max. Major) if that happens due to stupid tools. Manually refactoring all these methods not always leads to a good balance of effort/quaility gain. IMHO the best approach is still to make our tools to properly format the code so things like this never happen and then the rule is just fine as no issues will be raised.

[hohwille]

Status:

• S2699 - severity lowered from blocker to info
• S3369 - no problem: devon4j projects do not have web.xml anymore. Projects that do have it might take value from the rule or mark the single finding as not an issue/false positive.
• S2063 - has been removed
• S00121 - no problem: rule is fine. We need to fix devonfw-ide settings for eclipse.

Therefore considering done and closing.