parasoft jtest – a review

Main menu:

Topics

Recent Posts

Blog

June 2009
M T W T F S S
« May   Jul »
1234567
891011121314
15161718192021
22232425262728
2930  

Past Posts

Java/Java EE

JDBC

Other

parasoft jtest – a review

June 28th, 2009 by Jeanne Boyarsky

I tried running Parasoft’s JTest against the modified JForum use by JavaRanch.

The first thing I did was run all the static analysis rules and got over 47 thousand hits.  Now this doesn’t mean much as some of the rules are cosmetic things and some directly confict with each other. (Use “*” for imports and don’t use “*” for imports imply every single file with get hit for one of them.  I started running all the rules so I could drill down and see what was out there.

A few of the rules were things that I had already noticed and made me cringe when reading the code.  For example, PostAction as a cyclomatic complexity (branch count) over over 40.  Ten is high.  40 is almost unreadable.

Some of the more interesting ones:

  • Found some duplicate code and string literal duplication.
  • The rules were updated for Java 5 – For example, it found I overwrote toString() but not valueOf() in an enum.
  • security rules for SQL injection
  • I really like “remove commmented out Java code” as this is a pet peeve of mine!
  • I learned that there is a problem with “double checked locking” pattern if you don’t use the volatile keyword.
  • As expected, JTest found unclosed resources, missing static keywords and the like.
  • There’s a bug in Java’s substring implementation that can cause an out of memory error.
  • It didn’t find a specific defect I was hoping to uncover when I downloaded it.  But this was more informative than not – now I know that defect isn’t in the code without having to look through hundreds of classes!

Some of the rules offer a “quick fix” where you can automatically fix the violation through your IDE plugin.  I used this to add {} to single line conditionals in 50 places without effort.

The only complaints I ran into:

  • It’s mostly updated for Java 5, but not completely.  One rule says to using StringBuffer instead of String when concatenting strings (when you should use StringBuilder.)
  • It’s slow – 5 minutes – 11 rules – 519 files.  PMD goes faster.
  • And of course – it’s expensive – but it’s intended for corporate users.  Thank you Parasoft for the trial to use on our non-commercial software!

The breadth of errors JTest can find is amazing.  It doesn’t just save you time manually reviewing code – it tells you about subtle errors you might not know about.

Write a comment