Cover rules from Eclipse JDT

Clean Code New rules / language support
1

I like the idea to have a centralized single solution for static code analysis. I’d like to introduce it to my company department. However, a minimum set of Java rules is required to do so. This is because we are primarily using Eclipse as an IDE and make good use of the static code analysis rules offered by the Java Development Tool (JDT). By default, only some of them are enabled, but more can be activated under Window>Preferences>Java>Compiler>Errors/Warnings. I tested both SonarLint and SonarQube against these rules and was kind of disappointed that quite some important cases are not detected. Some of them are the following (names are the official ones of the rules):

  • Indirect access to static member
  • Access to a non-accessible member of an enclosing type (Here I’d rather like to have “Access to a non-accessible member of a NESTED type” only, but the JDT detects both)
  • Unlikely argument type for collection methods using Object
  • Incomplete switch cases on enum
  • Potential resource leak
  • Usage of raw type
  • Unchecked generic type operation
  • Type parameter hides another type
  • Missing synchronized modifier on inherited method
  • Unqualified access to instance field
  • Resource not managed with try-with-resource
  • Hidden catch block
  • Unnecessary cast or instanceof operation
  • Redundant null check
  • Potential null pointer access
  • Method can potentially be static

Documentation can be found here http://help.eclipse.org/photon/index.jsp under Java Development User Guide > Reference > Preferences > Java > Compiler > Errors/Warnings.

Are there any plans to pick up more rules from Eclipse? Again, it would be a minimum requirement for our department.

4

Hello Werner,

We don’t have a plan in itself to cover the rules already covered by Eclipse mainly because they are already there so normally they are already followed and fixed by developers. We generally re-implement rules when we believe we can provide better results. I believe that’s the case for the NPE detection one for example.
That said, I looked at what you would expect to find in SonarLint / SonarQube and I think we already cover some of them:

So, from your list, I think we need to look at this remaining items and see if there is a high value to implement them in SonarLint/SonarQube:

  • Indirect access to static member
  • Access to a non-accessible member of an enclosing type (Here I’d rather like to have “Access to a non-accessible member of a NESTED type” only, but the JDT detects both)
  • Unlikely argument type for collection methods using Object
  • Usage of raw type
  • Unchecked generic type operation
  • Type parameter hides another type
  • Missing synchronized modifier on inherited method
  • Unqualified access to instance field
  • Hidden catch block
  • Method can potentially be static

Direct link to the Eclipse rules documentation: http://help.eclipse.org/photon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fpreferences%2Fjava%2Fcompiler%2Fref-preferences-errors-warnings.htm&cp=1_4_2_0_3_1

In all cases, that should not prevent you to starting using SonarLint/SonarQube and take advantage of the 498 rules provided by SonarJava.

If you want to help us in this effort to re-implement these rules, you are welcome. In that case, we will need for each of them the following information:

  • a description explaining why this important to catch this problem - what bad can happen if the developer is not fixing it
  • a “Noncompliant Code Example”
  • a “Compliant Solution” sample

Regards

7

Thanks for you reply. I have rechecked all the mentioned rules, created a minimal example for each case which is still missing in SonarJava and created new topics for them. This post can now be deleted if wished.