Coverity recently released the first version of their new product Software Readiness Manager for Java. Software Readiness Manager collects and analyzes essential data from multiple sources and provides analysis on aspects such as as code complexity, violation of best practices, architectural integrity, interdependencies, and test coverage. It provides development managers with insight to assess risk, prioritize refactoring, and assess software readiness.
In addition to Software Readiness Manager also makes a number of other Java code analysis tools. InfoQ recently sat down with Andy Chou, chief scientist at Coverity, to discuss Coverity Prevent and Thread Analyzer.
Coverity Prevent for Java was a result of the C++ version of the product. What was the inspiration for Thread Analyzer?
We saw the trend towards multicore processors, and from experience we knew that multithreaded programs would begin to behave differently on this new hardware. Specifically, problems such as race conditions and deadlocks that lie dormant could suddenly become major problems. These problems are among the most difficult to debug because they are very hard to reproduce. Our static analysis product, Coverity Prevent, also detects concurrency defects, but we knew that dynamic analysis could complement the static results by finding even more concurrency defects during testing. This led us to develop Thread Analyzer, and so far the response from our customers has been very positive.
How would you define the ROI proposition for Thread Analyzer in comparison to profiling tools such as Yourkit?
Thread Analyzer is focused on some of the most pernicious problems in programming multithreaded code. It can take days to weeks to reproduce and find a concurrency defect. Even after isolating a problem down to a few crucial lines of code, it can be difficult to untangle the interleaved events required to make a race condition or deadlock occur.Thread Analyzer makes these very clear and reproducible, so it can provide tremendous savings when it finds a problem that's currently being debugged or, better yet, while an application is being tested. Profiling tools do quite a few things, including breaking down where time and memory is being spent in an application. I would say that they are complementary tools, and the value of each depends on the kind of application being developed and situation at hand.
A recent meme from the blogsphere has been Open Source is Killing Commercial Developer Tools. How has open source effected your business?
Open source has been a boon for our business -- every code base provides an extensive test of our static analysis system, and we've used that to great advantage by tuning our algorithms to minimize false positives and maximize bugs found, all without having to leave the lab. We are also proud to provide the open source community with defects found by our tools at Scan (http://scan.coverity.com). So far over 8000 defects have been fixed by open source developers looking at the Scan results. In terms of open source tools, they do have an effect on the developer tools market, but we find that there is plenty of room for tools that use advanced technologies, provide enterprise features and support, and are diligent about investing in their core value to stay ahead. Tools that attempt to be cash cows without improving themselves -- they get run over by open source."
What is the number one issue that you have seen for Java developers creating multithreaded applications?
Originally we thought that race conditions would be the most important problem, because they can cause data corruption and they are especially hard to work backwards to find a root cause. However, we've bene surprised that many customers tell us that deadlocks are even more important to them because they can cause an application to completely halt. Even in our own internal development, our enterprise architect has said that he views deadlocks as a major problem in testing and deploying enterprise applications on the Java platform. These views may reflect some lack of awareness that race conditions can cause serious data corruption... Deadlocks are immediately apparent, whereas race conditions may not ever be noticed, depending on the nature of the race.
What features are you working on for the next version of Thread Analyzer?
We plan on a tighter integration with our static analysis products, so they can share information with each other to help improve performance and find even more defects. We also plan on working on detecting concurrency problems in distributed programs that use multiple servers. Finally, we're exploring integration with platform vendors to reach a much wider audience with Thread Analyzer
