Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

Java Static Analysis And Custom Bug Detectors 157

Posted by Hemos from the developerworks-ftl dept.
An anonymous reader writes "Java static analysis and custom bug detectors can be a very cost-effective way to improve software quality. By creating a detector for a known bug pattern, we can search for that bug pattern not only in the current code base for a specific project, but in any project, current or future. This article looks at how static analysis tools can change the way you manage software quality."
This discussion has been archived. No new comments can be posted.

Java Static Analysis And Custom Bug Detectors More

Java Static Analysis And Custom Bug Detectors

Comments Filter:

  • PMD and JLINT (Score:4, Interesting)

    by Hoolala ( 976766 ) on Monday July 03, 2006 @12:13PM (#15650596) Homepage
    We develop Java-based vertical products and we have found PMD and JLINT when integrated with an appropriate development process, can be highly effective in preventing serious bugs. That said, both PMD and JLINT incorporates "religious" issues, and it is important to determine what the religious issues are and steer clear of them lest the good rules get lost among the non-essential (from project perspective) rules.

  • FindBugs is awesome (Score:5, Informative)

    by tcopeland ( 32225 ) * <tom AT thomasleecopeland DOT com> on Monday July 03, 2006 @12:18PM (#15650627) Homepage
    As the lead guy on a "competing" static analysis framework - PMD [sf.net] - I can say that FindBugs is definitely a great piece of work. It catches all sorts of complicated problems with concurrency, does forwards/backwards data flow analysis, etc, etc. It's pretty sweet. Dr Pugh, who runs the project at the University of Maryland, did a JavaPosse interview [javaposse.com] that's some more good info on the project and where it's going.

    Of course, if you really want to do source code analysis (vs bytecode analysis, which is what FindBugs does), then go for PMD, and [plug] get the book [pmdapplied.com]! [/plug]
  • "By creating a detector for a known bug pattern, we can search for that bug pattern not only in the current code base for a specific project, but in any project, current or future."

    Does it require a 1.21 gigawatt [wikipedia.org] lightning bolt to power the future search feature?

  • Not just bugs, but lint for bad practices... (Score:3, Insightful)

    by Speare ( 84249 ) on Monday July 03, 2006 @12:33PM (#15650733) Homepage Journal

    You should run whatever LINT-like tools you can find. Developers should agree as a group on what warnings are spurrious and what warnings are legitimate, and adjust any lint policy configurations to suit.

    You can also find far more than simple bugs, but you can decide on best practices and consistency standards which should be adhered also. These can vary in importance, but it really helps for a clean and searchable codebase. For a trivial example, if coding in C, decide as a group whether to use *p = '\0' or *p = 0 when writing into a char string. For a more involved example, regularly scan the codebase for regular expressions like (>)\s*(8|16|24) to find possible Intel/PPC endian issues lurking where you don't expect it.

    The adage goes, if you find you're doing something more than once, see if you can automate it, so you can pay more attention to the things which can't be automated. This goes for coding and debugging too.

    • Should have known that the HTML and the C would have butted heads...

      Regular expressions like: (<<|>>)\s*(8|16|32)

      Also, run your code through more than one make of compiler if you can: each compiler has its own set of warnings, and if you can pass them all cleanly, you can get closer to a "best in breed" codebase.

  • are these actually worthwhile? (Score:3, Insightful)

    by buddyglass ( 925859 ) on Monday July 03, 2006 @12:56PM (#15650879)
    Not having used any static analysis tools, but having worked on several java projects, I question how useful these tools are. In my experience, most bugs that could be detected by static analysis are usually caught relatively quickly anyway. The trickiest (and potentially most damaging) ones are usually non-general enough to slip past a general-purpose tool. Am I mistaken?
    • Am I mistaken?

      That depends on the quality of your code. It's easy enough
      to find out, though: install one of the tools (it only takes
      a few minutes), try it on some of your production code, and
      see how many real bugs it finds. Most people are surprised
      by the results, but I make no guarantees about yours.

      It can also save time in catching subtle bugs, even if it
      doesn't recognise them directly, by early on pointing out
      trival mistakes that would make them hard to diagnose and
      potentially spend hours barking up the
    • I'm not sure how that post is "Funny," but the things modern static analysis are typically written to catch are concurrency problems. Java isn't quite plagued as much by the incorrect usage of pointers in C that inspired the creation of lint, but multithreading code is still dangerous and difficult to get right. At the very least, these things are usually quite self-sufficient; you'd be a fool to turn them down a daily generated report even if it doesn't catch EVERY potential pitfall.
      • Obviously it's not something I'd turn down or ignore, if it were already set up and integrated into my build scripts. It's just a question of whether it's worth the effort required to set it all up and get it running daily. Maybe the effort level to achieve that is relatively low, in which case it would be worth doing.
        • Most are trivial to run on your code, in a one off fashion. Try one or two and see what results they give you. If they find a lot of issues then it may be worth your while investing the time to integrate one, or more, of them into your build system. If they don't then don't use them.
    • Although what you say may be true in that complex or not so straight-forward bugs are more difficult to find, I have seen many a time myself or another developer struggling with a bug for a good 2-3 hours and as soon as another set of eyes looks at the code, he/she points out something obvious, simple, that was wrong with the code. This I have seen more than a few times, surely. So I think there's still merit to a static analyzer/bug-finder, even though it may not be able to find complex problems.
    • Well, simply said, if you aren't mistaken, I would go back and grab C++, which can do more and for which there are more libraries for. In Java, it's a lot harder to make mistakes due to the inherent readability of the language, both for people, but also for tools. That said, it's still easy enough to make a mistake.

      Please try the book "Java Puzzlers" if you are certain that you can find most Java bugs. I could figure out most bugs, although probably not on first sight. And definately not on first sight on a
    • Not having used any static analysis tools, but having worked on several java projects, I question how useful these tools are. In my experience, most bugs that could be detected by static analysis are usually caught relatively quickly anyway. The trickiest (and potentially most damaging) ones are usually non-general enough to slip past a general-purpose tool. Am I mistaken?

      I think it depends on how good you are and how well you use the tools. My IDE (IntelliJ IDEA) has some static analysis built in and it's
    • "In my experience, most bugs that could be detected by static analysis are usually caught relatively quickly anyway."

      In my experience the *opposite* is true, at least for code that I am not writing myself.

      For instance, since I started using FindBugs on our project (which is fairly large and complex as these things go, with ~5 development teams working on it and with many threads running at the same time), I've caught several potential deadlock issues that would have probably been uncaught until a deadlock h
  • ...is Sun's Jackpot [netbeans.org], headed up by Tom Ball. What's neat about Jackpot is that it does problem fixing, too, using a domain specific language. From the interview:

        $object.show() => $object.setVisible(true) ::
                $object instanceof java.awt.Component;

    Feeding that DSL snippet to Jackpot will transform all Component.show() calls to Component.setVisible(true). Very, very cool stuff. Of course, you don't always want to make the transformation, but in the cases where you do, Jackpot looks like a great solution.

  • doesn't findbugs do this (Score:3, Interesting)

    by josepha48 ( 13953 ) on Monday July 03, 2006 @01:08PM (#15650951) Journal
    I think findbugs does this. I've started using it and it found lots of bugs in my code. As a result I have learned a few things about java, just by using it and fixing my bugs.
  • If this bug detection is as good as they say, it should be part of the compiler. If it is not good enough to be part of the compiler, I wouldn't bother with it.
    • Amen. What do they mean with 'patterns' in this case anyway, or is it just a fashionable excuse to name-drop the term 'pattern' again ? The one example they're giving is so easy to circumvent, and so difficult, therefore, to detect, that I wish them all the luck in the world if they're planning to concentrate on this. I'd go for easier options, me, indeed as part of the compiler:

      boolean b; if (b = false) { ... }

      while (in.readline() != null) { String str = in.readline(); } // seriously, I came across this
      • Many of these checkers are basically advanced pattern matchers. They contain a set of pattern templates that will match code (or bytecode) that contains bugs. They check for, as an example, a variable that is used without a check (if(null!=bla)) but may not be assigned. The compiler does not catch this because the variable is not marked final. Its a trivial pattern to check for.

        They can also perform some concurrency checks. Such as looking for a pair of locks that are obtained in different order in differen
        • Which supports my original statement: I wouldn't bother with these detectors, I would rather insist on updated unit-tests and add more unit-tests as new bugs are discovered and fixed (including race-conditions.)
          • Unfortunately you cannot write unit tests that will find all race conditions. They may find some (common one that will occur often) but unless they can run forever they will not find all. These detectors are a useful tool, nothing more, nothing less. They are not supposed to replace good unit tests. However they can find issues that units tests cannot. Even if your unit tests give you 100% coverage that only means that they exercise all of your code. It does not mean they excersie all of your code in all si
            • Of-course unit-tests can't find all race conditions. But this bug-detector won't find all race conditions either.

              Again, I wouldn't bother with it in most real-life situtations. We all have deadlines and resource limitations. Besides Java is mostly used on the back-end today and it is mostly used within some J2EE container. Manual thread management should be avoided as a matter of principle in these situations and the resources that are shared must be thread safe. The best thing to do is to avoid comple
              • I can only suggest that you try one and see what it does for you.

                J2EE is a framework that tries to hide multithreading issues from the coder. As such (and per recomendation by sun) you should try to avoid creating your own threads. However threading issues still affect you. Perhaps it is a cache you need all servlets/beans/whatever to use. You may be able to use a third party library you may not. Even if you do use a third party library are you 100% confident that it has no synchronization/threading issues?
                • Perhaps it is a cache you need all servlets/beans/whatever to use. - taken care of by the EJB container. If you are talking about static caches (such as collections) there are thread safe patterns to handle them.

                  Even if you do use a third party library are you 100% confident that it has no synchronization/threading issues? These tools can help. - help with what? You are giving a blanket statement here that the tools will help with something. I say don't bother unless there is a problem. Sure, if there
                  • Profilers are very usefull. Unit tests are very usefull. Static code checkers are also usefull. Try one. Unless your codebase is perfect they will find issues with it. Many of the issues will not be bugs (depending on the options you set on the checker) but will likely indicate a poor or overly complex coding style. It will likey take 30 mins of your time to assess the utility of the checker. It may save you far more time then that. I partially agree with you that the checkers are not as good as some of thi
                    • Fom this statementI take it that you only write unit tests after you have found a problem. After all unitll your code fails there is no problem therefore no reason to write unit tests. - that's a pretty bizarre inference. No, I write unit tests either before or during development of the actual business code. But these bug detectors don't make much sense if normal testing and operations show no problem.

                      Even if the static checker finds no issues with the code that is failing it has just ruled out a large nu
                    • Fom this statementI take it that you only write unit tests after you have found a problem. After all unitll your code fails there is no problem therefore no reason to write unit tests. - that's a pretty bizarre inference. No, I write unit tests either before or during development of the actual business code. But these bug detectors don't make much sense if normal testing and operations show no problem.

                      It was taken directly from your statement:
                      I say don't bother unless there is a problem.
                      that you sh
                    • Found a wireless connection in the parking lot :) Everyone has evacuated and they won't let us back into the building today.

                      It was taken directly from your statement: - this is my attitude towards profilers and debuggers. Don't bother with them, unless you know there is a problem. I developed this attitude over the past 10 years of work related experience and it serves me just fine. YMMV.

                      that you shouldn't invest in preventative measures, as they are an expense, without reason to do so. You write unit t
              • This is a stupid argument, because running these automated tools is pretty easy. I mean, it can find bugs without all this tedious unit-test writing. Of course, it does not relieve you from writing unit tests, and neither does it mean that it will find every possible bug. But most of the time it only takes limited amount of configuring in your software street, and every time you build something, you check out the bugs that have been found. In other words, the finding of bugs is almost for free. So why not u
                • I mean, it can find bugs without all this tedious unit-test writing. - this 'tedious unit-test writing' is the only way to make sure that the business rules are asserted. Concurrency problem is a non-problem for most applications. In case of Java, J2EE container handles the concurrency issues. Configuring another tool just for the sake of configuring just another tool is a waste of resources and cannot be always justified. I would rather see my people spend more time writing unit-tests than configure po
                  • I specifically told in the post that it does not replace unit writing. Just that it is pretty easy to run, regardless of unit-testing. It's not that hard to configure these tools, especially when you are doing it for a whole team. I've switched on PMD and walked through an entire project in one day, switching off the more useless (in my opinion) tests as I went along. This takes much less time than writing Unit tests. So why not combine both. What kind of brainless moderator put my posting down as flamebait
          • "If this [unit test] is as good as [you] say, it should be part of the compiler. If it is not good enough to be part of the compiler, I wouldn't bother with it."

            Your statement is ludicrous. That something isn't part of the compiler does not make it not useful. Taken ad absurdum, do you *ONLY* use the tools that are part of your compiler, and not, say, your IDE? Eclipse, IDEA, etc. have many useful tools that help solve problems, preempt issues, help you out... do you not use those? Why not use the tools
            • Your statement is ludicrous. That something isn't part of the compiler does not make it not useful. - a logical fallacy. I didn't say that anything that is not part of a compiler is not useful.

              Taken ad absurdum, do you *ONLY* use the tools that are part of your compiler, and not, say, your IDE? Eclipse, IDEA, etc. have many useful tools that help solve problems, preempt issues, help you out... - you are saying this, not me. I didn't say Eclipse is not useful because it is not part of the compiler. I don'
  • I've used lint4j, pmd, checstyle and indeed findbugs. These tools are very useful. The biggest problem is finding the time to fix the issues. It's tempting to skip the minor issues but then this is where you need to be strong.

    I'd recommend that serious java developers integrate the above mentioned tools into their nightly builds and treat the identified issues as real bugs.
    • As long as you take time to look at each bug. E.g. in PMD, it will find every field and local variable that could have been declared final. I don't even want those bugs as a warning. I want those as a tip, that does not show up as a warning for each build. It will not matter in 99% of the cases. Also, these kind of bugs should be automatically fixed, since they can be (maybe with a review screen beforehand, to exclude the ones that don't need fixing.
  • IntelliJ Idea (http://www.jetbrains.com/), a java IDE, has had "custom bug detectors" in it for a while. And you can add your own, via the plugin api, and you can select which ones you want on/off, and its part of the tool, like it should be. You get a GUI for fixing it, that matches compiler based syntax errors, etc. Makes me wonder if IntelliJ features came first, or this open-source project did. Anyone know?
  • As an example of turning bug instances into bug patterns, I always read through the list of bugs fixed in each version of the jdk1.6.0 builds. In build 89, a bug was fixed in the serialization of ArrayBlockingQueue [sun.com].

    I wrote a FindBugs bug detector to look for similar cases: a class with transient fields, but no readObject or readResolve method to restore the field. I had to tune the detector a bit (for example, raise the priority if it is set to a non-default value in the constructor). I'm still doing some

Slashdot Top Deals

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Close