Find all the bugs!

Know your Java static analysis tools

DaneMarcelo
bug

A helpful summary of some of the most useful Java static analysis tools around.

There are many Java static analysis tools kicking
around. Each one focuses on a specific area and has its own
distinct advantages. Here’s a helpful summary:

Pmd: a static rule-set based
Java source code analyser that identifies potential problems
like:

  • Possible bugs – Empty try/catch/finally/switch blocks.
  • Dead code – Unused local variables, parameters and private
    methods.
  • Empty if/while statements.
  • Overcomplicated expressions – Unnecessary if statements, for
    loops that could be while loops.
  • Suboptimal code – Wasteful String/StringBuffer usage.
  • FindBugs: Looks for bugs in Java code. It uses static analysis
    to identify hundreds of different potential types of errors in Java
    programs.
  • Checkstyle : Defines a set of available modules, each of which
    provides rules checking with a configurable level of strictness
    (mandatory, optional, etc.). Each rule can raise notifications,
    warnings, and errors.

Many ways exist to exploit the results of these
tools:

  • XML format: XML files can be generated from each of
    these tools, and it can be used to create an HTML report or used by
    another tool to exploit the analysis result.

  • HTML format: HTML report is the preferred way to
    generate reports and share them between the team, and you can
    create your custom report by using an xsl stylesheet.

  • IDE Plugins: almost all known IDE provides plugins for
    these tools, which can discover all violations from the source
    code.

One of the problems with code quality tools is
that they tend to overwhelm developers with problems that aren’t
really problems – that is, false positives. When false positives
occur, developers learn to ignore the output of the tool or abandon
it altogether.

And to better exploit their results, it’s better to
have a way to focus only on what we want, and give a useful view to
developers. In this post we will discover another interesting way
to exploit better the result of all known Java static analysis
tools, and query them like a database.

JArchitect and CQLinq

JArchitect is
another static analysis tool which complements the other tools. It
uses a code query language based on Linq ( CQLinq) to query the
code base like a database.

With JArchitect 3, you could only query analysis data
extracted from JArchitect, however, V4 allows you to import
analysis results from many other static analysis tools and query
them with CQLinq.

Let’s take as example the source code of the PDT core
(the Php plugin for eclipse) and discover how we can exploit the
analysis result of these tools from JArchitect.

To begin, here are the steps to follows before
requesting the analysis result:

Step1:

  • Analyse the project with PMD, CPD, FindBugs and
    CheckStyle, and generate the XML files containing the result.

Step2:

  • Analyze the project with JArchitect.

Step3:

  • Import all the xml files into JArchitect from the menu
    “Plugins->Import Plugins Result Files”

JArchitect provides by default many useful queries to
request these tools, and all these queries can be easily
customized.

Let’s discover some CQLinq queries:

Get all issues:

The request to get all issues is very simple, however
as you can see, it’s not very interesting – indeed it’s a challenge
to exploit a result with 232 725 issues.

To exploit better the result of these tools we can
filter it with CQLinq and focus only on what we want.

Request by tool

We can modify the first request and add a criteria
about the tool concerned.

Request by ruleset

We can also filter by issue ruleset :

Request by priority

We can also filter by priority:

Most recurrent issues

It’s interesting to know which issues are the most
reported by these tools.

Classes having most issues

It can be very interesting to find out the classes
that contain multiple violations.

As we can observe, CheckStyle reports thousands of
issues, and many of them can be ignored.

The previous query is interesting, but it does not
give us the exact classes with quality issues. Another useful
metric to take into account is the NBLinesOfCode. It’s normal that
a class with many lines of code contains many issues, and for that,
we can modify the previous request to calculate the ratio between
the Issues count and the NBLinesofCode.

What’s very strange in this result is that the ratio
of the eight first classes is more than 200. In this case we have
more than 200 issues by code line.

To explain this behavior let’s take a look at some
lines of the CompilerAstParser:

The NbLinesOfCode is the number of statements and not
the physical lines, and this Class declares many arrays. Each one
is declared by thousand of physical lines, however each array
declaration is considered as one statement.

And, as shown before for the most recurrent issues
query, the following rule ‘+’ should be on a new line. is violated
thousand of times for each array. Maybe it’s better to remove these
kind of rules from the CheckStyle configuration file.

Most popular methods having issues

When the static analysis tools report the issues, it’s
useful to locate the priority issues to resolve – especially if
there are bugs involved.

It’s true that a bug could exist in a specific method,
but what interesting to know is how many methods are impacted by
the bug, and the popular method are the most used ones and it’s
better to resolve them quickly.

Using CQLinq we can combine the result of all these
tools and also the result of JArchitect to create more elaborated
queries, and add these checks to the build process.

Issues Trend

Having issues in a project is not an exception, we can
say that’s normal, however we have to check the quality trend of
the project. Indeed it’s a bad indicator if the number of issues
grows after changes and evolutions.

JArchitect provides the Trend Monitoring feature to
create trend charts. Trend charts are made of trend metrics values
logged over time at analysis time. More than 50 trend metrics are
available per default and it is easy to create your own trend
metrics.

Let’s create a trend metric for the Pmd issues:

And after you can easily create the trend chart to
monitor the previous trend metric and add it to the JArchitect
dashboard.

With this trend chart we can monitor the evolution of
the Pmd issues, and try to understand the reasons when the metric
grows over versions.

Customize the JArchitect report

JArchitect make possible to append extra report
sections in the HTML report that lists some CQLinq queries.

In the CQLinq Query Explorer panel, a particular
CQLinq group reported is bordered with an orange rectangle.

You can also add to the report the Pmd trend
chart:

And in the HTML report these added sections are
accessible from the menu:

And here’s the page added in the report for the Pmd
CQLinq queries:

Conclusion

JArchitect 4 is now open to other static analysis tools, and you
can also plug your customized tool easily as described here. This
way you can use all the JArchitect features to exploit better the
result from the known java static analysis tools.

This post was originally published on javadepend.wordpress.com/

Image by felinebeastie

Author
Comments
comments powered by Disqus