2

When enabling SONAR on an in-house Java project, there are a large number of violations being reported due to the rule DesignForExtensionCheck. Whilst I agree with the theory that all classes/methods should be marked up as being either Abstract, Final, etc. But is it strictly necessary for an in-house application where the developers have full contorl over the code base and unit tests etc?

An example is a Value Object who's every getter/setter is required to be final to pass this check. When you have 500+ such issues being reported its a big ask to retrofit the code.

Some people have stated that Java has some flaws, and one of those is that classes/methods are not final by default. Bearing in mind that we don't have final as the default behaviour how much effort do we realy have to go to declar everything as final?

Note: I realise that API's being used by third parties must have tighter controls. This question is levelled at in-house applications.

Improve this question
1
  • Came across this, note that DesignForExtension has been removed from the default Sonar server checks in the newer server versions (and good riddance too!)
    – Alok
    Jul 24 '13 at 0:12
1

We have the same issue in our legacy app. I was the one who enabled this rule at the beginning, but I am not happy with the result. Fact is, many classes and methods we can't even declare final, because that would make it impossible to mock them in unit tests. And mock them we must, because some of them are so tangled up, there is no other way to initialize them in a test fixture. (We use EasyMock, for the record, but I am not aware of any Java mocking framework which could do this trick.)

At any rate, we have many more important rule violations reported by Sonar, so I am not worried about this very much. Maybe at the point where most of the more important issues have been fixed, I can review how many of these warnings can be realistically eliminated, then once those are done, turn off this rule.

Improve this answer
1
  • 1
    I've been using Mockito so it's an interesting point you raise about maintaining testability. For final methods Powermock is a solution that works, however the readability starts to suffer a little.
    – Brad
    Dec 14 '11 at 22:50
0

It's not the first rule I would be worried about if you have an internal app. Be aware though that if some other party within your org wants to use that app then some of those warnings should be heeded.

Some would say the warnings should be heeded regardless, has it been causing you major issues in PRD? If not, then don't sweat it, focus on the other areas.

Improve this answer
3
  • No prod issues. This issue is one of the few remaining now. I use ANT to create the SONAR reports and have been wondering how I could (if I should) try to disable this rule. The point raised below about still being able to mock in tests is vital
    – Brad
    Dec 14 '11 at 22:53
  • @Brad, is it so that you aren't allowed to edit the code analysis profile(s) on the Sonar server, or you just don't know how to do it?
    – Péter Török
    Dec 15 '11 at 8:56
  • I don't know how to do it. I was hoping I could control it via my ANT build script for this project only. I don't have access to configure the SONAR server as it is managed by another team.
    – Brad
    Dec 15 '11 at 11:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.