#93: changed rules priorities and removed one

[RSOKOLSK]

PR addressing issue #93

1. changed priority of rule "s2699 - Tests should include assertions" to INFO
2. changed priority of rule "s121 - Control structures should use curly braces" to MINOR
3. removed rule "s2063 - "Comparators should be "Serializable""

[lmarniazman]

Looks good, thank you!

[lmarniazman]

Actually, there is one change request. You included this in the other PR for #93, and probably forgot to put it here too. There is a bug in line 102 of DevonfwJavaProfile. The if-condition there should be negated, otherwise the new priority will not be set. Could you include this in this PR? Thanks a lot.

[RSOKOLSK]

Done, thanks for reminder.

[lmarniazman]

@hohwille
From the issue text, I also understood it in the way that S2063 should be removed because of this line:

Java Serialization is about dead. Do not use JEE App servers that serialize your objects silently into a session storage.

Or should this rule be replaced by our own implementation? We could create a rule that detects if java.io.Serializable is used and point the user to an appropriate alternative.

What might be confusing is that the title of the rule is slightly off here. Its real name is Comparators should be "Serializable" instead of Security Constraints should be "Serializable".

[hohwille]

1. For s2699 on INFO I am also fine and this is what I intended.

2. For s121 I am also not entirely sure.
   https://rules.sonarsource.com/java/tag/serialization/RSPEC-121
   Actually I agree with the rule and its severity in general and think the main problem comes from tools like Eclipse that generate code violating this rule. I will first check what we can do with the latest Eclipse version that IMHO has improved here.

3. @lmarniazman thanks for clarification. So we are talking about this rule:
   https://rules.sonarsource.com/java/tag/serialization/RSPEC-2063

Regarding the serialization I was more talking about this one:
https://rules.sonarsource.com/java/tag/serialization/RSPEC-2057

I am still thinking if we should keep these rules but on INFO level.
Further, I am more keen on removing the according warning from Eclipse default config in devonfw-ide.

So to summarize: With #93 I wanted to collect feedback and start a discussion. Implementing all as one PR was maybe to quick. But I try to clarify the above points so we can finalize this PR and merge it to make progress.

[hohwille]

devonfw/ide#473

[lmarniazman]

Thanks for the input @hohwille

So for S121 and S2063, the severity should be kept at CRITICAL for now, and S2057 should be at INFO? Or should the severities of all three rules be set to INFO?

[hohwille]

IMHO only 2. was in question and S121 should remain on CRITICAL. Change 1. and 3. are fine as well as the fixed IF-statement. Could you find a way to revert the change of 2. so we can merge?

[hohwille]

I could edit directly on github. BTW: cool feature... So new we can merge.