Java Static Analysis And Custom Bug Detectors 157
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."
PMD and JLINT (Score:4, Interesting)
FindBugs is awesome (Score:5, Informative)
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]
Searching for future bugs? (Score:2, Funny)
Does it require a 1.21 gigawatt [wikipedia.org] lightning bolt to power the future search feature?
Re:Searching for future bugs? (Score:2)
Not just bugs, but lint for bad practices... (Score:3, Insightful)
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.
Re:Not just bugs, but lint for bad practices... (Score:2)
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)
Re:are these actually worthwhile? (Score:2)
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
Re:are these actually worthwhile? (Score:2)
Re:are these actually worthwhile? (Score:2)
Re:are these actually worthwhile? (Score:1)
Re:are these actually worthwhile? (Score:2)
Re:are these actually worthwhile? (Score:2)
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
Re:are these actually worthwhile? (Score:2)
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
Re:are these actually worthwhile? (Score:3, Informative)
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
Another nifty static analysis project (Score:3, Informative)
$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)
Why a seperate tool? (Score:2)
Re:Why a seperate tool? (Score:1)
boolean b; if (b = false) {
while (in.readline() != null) { String str = in.readline(); }
Re:Why a seperate tool? (Score:1)
They can also perform some concurrency checks. Such as looking for a pair of locks that are obtained in different order in differen
Re:Why a seperate tool? (Score:2)
Re:Why a seperate tool? (Score:1)
Re:Why a seperate tool? (Score:3, Informative)
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
Re:Why a seperate tool? (Score:1)
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?
Re:Why a seperate tool? (Score:2)
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
Re:Why a seperate tool? (Score:1)
Re:Why a seperate tool? (Score:2)
Even if the static checker finds no issues with the code that is failing it has just ruled out a large nu
Re:Why a seperate tool? (Score:1)
It was taken directly from your statement:
I say don't bother unless there is a problem.
that you sh
Re:Why a seperate tool? (Score:2)
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
Re:Why a seperate tool? (Score:1, Flamebait)
Re:Why a seperate tool? (Score:3, Insightful)
Re:Why a seperate tool? (Score:2)
Re:Why a seperate tool? (Score:2)
Re:Why a seperate tool? (Score:1)
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
Re:Why a seperate tool? (Score:2)
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'
use these chechers (Score:2)
I'd recommend that serious java developers integrate the above mentioned tools into their nightly builds and treat the identified issues as real bugs.
Re:use these chechers (Score:2)
Custom Bug Detectors are in IntelliJ (Score:1)
Custom bug detector I wrote for FindBugs last week (Score:2, Interesting)
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
Re:Why not use OCaml or Haskell? (Score:2, Insightful)
Your alternatives are probablement better in respect of quality due to their formalism but you'd have to convince your manager or boss to sign up with these solutions. Might be easier to stick with Java and
Re:Why not use OCaml or Haskell? (Score:2)
By a strange coincidence, that's also the only reason people make assertions like this.
Re:Why not use OCaml or Haskell? (Score:3)
Re:Why not use OCaml or Haskell? (Score:2)
Re:Why not use OCaml or Haskell? (Score:1)
For example:
Re:Why not use OCaml or Haskell? (Score:4, Funny)
Re:Why not use OCaml or Haskell? (Score:3, Informative)
Re:What a strange thing from IBM (Score:2)
Java is a strong typed language, which just mean that if you got a reference to a class A, then you know that the object is of the type A, or of a class that extend A. (And similary for the buildin types)
But that is far from enough to be bug free. Just a simple example (Yes, a bit silly, but it shows the problem)
public static int myFunction(int[] myArray,int index) {
return myArray[0]+myArray[index];
}
Now the question? Is th
Re:What a strange thing from IBM (Score:2)
Re:What a strange thing from IBM (Score:3)
public class B { }
public void f(B myB) { A myA=(B)myB; }
This will not compile at all, because there is no way to cast a B to an A.
If you have
public class Base { }
public class Derived extends Base { }
public void g(Base myBase) { Derived myDerived=(Derived)myBase; }
The function g is ok, and if myBase is infact an instance of Derived, then all is ok. If it is NOT an instance of De
Re:What a strange thing from IBM (Score:3, Informative)
You're kidding right.
Bar b = new Bar();
Foo f = (Foo)(Object)b;
Works just fine for me... Until you get the ClassCast Runtime Exception.
Now you might call this a contrived example.. Except that it's not.
How many thousands of function calls take Serializable or worse "Object" as a parameter? Virtually every IPC related activity does at some point. That includes all of j2ee, which are considered "enterprise" level coding frameworks.
Generics was a step in the right directi
Re:What a strange thing from IBM (Score:2)
Collection<Foo> myFoos = new ArrayList<Foo>();
Collection myUnsafeFoos = myFoos;
Bar bar;
myUnsafeFoos.add(bar);
Foo foo = myFoos.iterate().next();
Re:What a strange thing from IBM (Score:2)
which just mean that if you got a reference to a class A, then you know that the object is of the type A, or of a class that extend A. (And similary for the buildin types)
So one could say, that you can try to cheat on the compiler, but It don't care becasue it knows the jvm will stop the actuelly type convension at runtime if it is wrong.
Re:What a strange thing from IBM (Score:2)
Re:What a strange thing from IBM (Score:2)
Re:What a strange thing from IBM (Score:3, Interesting)
You missed the part where I compared it to cooperative multi-tasking.. You are wrapping the collection at constructor time, BUT half (and I do mean half) of the time you don't have control over the constructor to an object.. Especially if you are writing middle-ware code, which is most of what Java does - at least good application designs write most of their code in the form of middle-ware.
Take Sort for example... It can't depend on the
Re:What a strange thing from IBM (Score:2)
Re:What a strange thing from IBM (Score:2)
Cheating is:
class A {}
class B {}
A a = new A();
B b = (B)a;
Without any exception!
In C++ you would need to add a "*" to the declarations and you could write it like above and it would WORK!!!!
In Java the assignment causes a ClassCastException in C++ the assignment works (Depending on C++ language standard). In C++ ypu get likely a crash as soon as you use a method on the object b
a
Re:What a strange thing from IBM (Score:3, Informative)
In any case, C++ has all but abandoned the C-style form of casting, which forms the syntactical basis for Java's casting mechansims: currently C++ sports dynamic_cast (Java-style cast with dynamic type check, returns 0 if the cast fails), static_cast (does not do type checking, but still does a basic compile time check like java. It is present if there's no way that the cast can fail; at least if
Re:What a strange thing from IBM (Score:2)
Oh, really? After working with Java for the past 8 years, I sort of noticed that you can do this:
WhateverObject1 whateverObject1=new WhateverObject1();
WhateverObject2 whateverObject2=new WhateverObject2();
List list = new ArrayList();
list.add(whateverObject1);
list.add(whateverObject2);
SomeObject someObj = (SomeObject)list.get(0);
Now tell me again what will Java compiler do in this case if SomeObject is not the same as Whatev
Re:What a strange thing from IBM (Score:2)
Re:What a strange thing from IBM (Score:2)
Ok, over and out.
Re:What a strange thing from IBM (Score:2)
Re:What a strange thing from IBM (Score:2)
Not really true. C++ suppports three types of casts and one obsolete form that combines those three in some form I never can remember:
The () is really poor syntax and the usage is discouraged. (and shame on Java for adopting that syntax).
Of these, Java support dynamic_cast, expanded a bit to support primitive types. (which should never have been added, imho.)
Yes, C++ will accept nearly any cas
Re:What a strange thing from IBM (Score:1)
One would think that out of all people, IBM staff would be familiar with the ATM or the Halting Problem.
Just use a language that isn't Turing complete, and therefore can be guaranteed to terminate. http://www.e-pig.org/ [e-pig.org].
Re:What a strange thing from IBM (Score:2)
First, I don't see the relevance, so I suspect you don't understand the halting problem[*]. You've probably heard it phrased as in the Wikipedia article [wikipedia.org]: "a general algorithm to solve the Halting problem for all possible program-input pairs cannot exist. We say that the halting problem is undecidable over Turing machines." You've probably heard arguments reducing other problems to the Halting problem an
Re:What a strange thing from IBM (Score:2)
Judging by that first statement uou missed most of my point. My point is that there is no real advantage building extra tools to search for simple errors, while still not being able to combat real problems, like infinite loops, incorrect conditions, class cast exception, null pointer exception. ATM has relevance to all of the above-ment
Re:What a strange thing from IBM (Score:2)
I got that. My point was that you don't need to determine if an arbitrary program is error-free in all of those categories to have a useful tool. If static checkers can point out a bunch of errors in a huge
Re:What a strange thing from IBM (Score:2)
Re:What a strange thing from IBM (Score:3, Informative)
Re:What a strange thing from IBM (Score:2)
{ <M,w> | M is a Turing Machine and M accepts w }
the angle brackets are a bitch to type in HTML.
Re:What a strange thing from IBM (Score:2)
Why would you not want a program to catch bugs for you? The only reason you write unit tests is because the language and tools you're using are not powerfully enough to detect these problems statically. I take an exception with this one.
Unit tests are not only about correctness of the language constructs, unit tests complement documentation, they are business constructs and no detector can
Re:What a strange thing from IBM (Score:2)
Re:What a strange thing from IBM (Score:2)
Re:What a strange thing from IBM (Score:1)
Anyone can write pretty code to hibernate and make huge mistakes.
Same with pretty much every other framework.
In the given example...wouldnt the test have failed?
All hammers are not equal true. But you have to be able to carry
your toolbelt to work and at work without breaking your back
and your shops.
Re:What a strange thing from IBM (Score:2)
Technically, "intractable" doesn't mean "mathematically impossible," but "too big to manage," so the solution you propose would fall under the "intractable" category.
Also, while you're probably already aware of this, the standard limitations apply to your solution: no external input can be available, and no race conditions can exist in the program.
Re:What a strange thing from IBM (Score:2)
for(;;) {
if (something is true) {
break;
}
}
No infinite memory, just uncertain state of 'something'.
Also, Java being strongly typed means little in terms of bug preventions. - I actually meant strong AND static typing. Static typing would prevent most non-business bugs. It would prevent serialization, reflection, inheritance and collection element castin
Re:What a strange thing from IBM (Score:2)
This is a program that will never have the same memory pattern, and (given infinite memory) will never terminate.
The stop problem is undecidable in general; in very special cases you will get a 'yes' or a 'no', but never in general.
Re:That's great... (Score:5, Informative)
C/C++ applications tend to work for decades and can be written to be far more reliably cross-platform.
Odd. I have found exactly the opposite. Java is very well know for the excellence of its backward compatibility, and to say 'all your old applications don't work anymore' is just plain false. Java would not have had the huge success it has had if this were not the case, so your statement is plainly wrong.
On the other hand, C/C++ version bugs are well known and well documented - just think of the issues involved with gcc versions and linux kernel compilations. I have a very simple C++ app that compiled and ran fine on one version of gcc, but broke on another.
If you simply exchange C/C++ for Java, and vice versa, throughout your post, it then makes sense.
Re:That's great... (Score:2)
I don't know the GP from a bar of soap, but if you're going to call someone a liar how about you check your facts first.
Re:That's great... (Score:2)
It is great the way that posters assume things! I work on substantial Java applications daily - apps with hundreds of thousands of lines of code.
There are very complex Java applica
Re:That's great... (Score:2)
Talk about the pot calling the kettle black. You called the GP a liar because his experience didn't match yours. How dare you then come back and point the finger at someone making assumptions you hypocrite!
There are very complex Java applications that run unchanged on different versions of Java - JBoss, NetBeans for example. These are app servers and IDEs - it is h
Re:That's great... (Score:2)
No, I did not call the GP a liar. I am careful with wording.
Well I have. "It works for me on my machine so stuff you" is nonesense that no professional should be uttering, let alone calling a perfect stranger a liar because they've seen something you haven't.
Again, I did not call him a liar.
Explain my ex
Re:That's great... (Score:2)
In your latest post again you insist that because you haven't in your very limited experience seen Java apps break, that it's rare. It's not.
Google for the following phrase:
java 1.5 breaks application
You get such links as:
http://developer.apple.com/qa/ [apple.com]
Re:That's great... (Score:2)
No, I was clearly saying that complex apps obviously don't break with version changes.
In your latest post again you insist that because you haven't in your very limited experience seen Java apps break, that it's rare. It's not.
Yes, a very limited exper
Re:That's great... (Score:2)
Re:That's great... (Score:2)
I have never said that no apps ever break with JRE upgrades, or that you never need to test things with different JREs
What I have actually said is that issues with JRE updates are rare. Java is one of the most backward-compatible systems ever produced. Nothing you have said and no links you have provided have demonstrated otherwise. You seem to be considering matters of how to access JREs or h
Re:That's great... (Score:2)
Let me say you have a tendancy to word things so as to imply other things, then back down when confronted with facts.
What I have actually said is that issues with JRE updates are rare.
I say bollox to that.
Java is one of the most backward-compatible systems ever produced.
It's one of the most widely used systems that has been designed with backward compatibility in mind, I grant you that.
Nothing yo
Re:That's great... (Score:2)
Your credibility = 0
I second the zero. Cough up some code, troll, or admit that you're a 15 year old who recently wrote a CS101 fibonacchi generator in C++ and thus you hate java because all cool c++ gurus on teh intarwebz do.
Re:That's great... (Score:2)
http://java.sun.com/j2se/JM_White_Paper_R6A.pdf [sun.com] [sun.com]
Getting your adolescent friends to second your opinion or creating a second account to bolster yourself is completely juvenile.
For your info I'm over 30, have a bachelor and masters, and have been doing this for some years...all of which has no bearing on the truth of what I've said of course.
Re:That's great... (Score:2)
The "fantasy" I'm trying to propogate? You're truely dillusional and brainwashed if you believe that upgrading or changing your JRE can't break your apps. Have fun living in your fantasy. A credibility raiting from a fool is of no interest or consequence to me.
Re:That's great... (Score:2)
This is often the case for pre-standard C++ programs.
(1) It was indeed C++.
(2) This has been an issue with C/C++ - compilers that are allowed to label themselves as C/C++ that aren't compatible. This is not the case with Java.
No libraries? (Score:3, Insightful)
That hasn't been a problem so far as even Java 1.1 applications will still work just fine today in Java 1.5.
That is because unlike other languages, Java has taken a lot of care to keep things working through revisions. Libraries going into disuse are deprecated, not removed - so you have a long time while a library or method call still exists before going away.
Even the design of Java's Generic
Re:That's great... (Score:1, Troll)
You've clearly never ever developed anything in Java before. Perhaps you've heard the saying "Do not hold strong opinions about things you do not understand"... I've been developing a fairly large Java application for over 5 years, and the old beta versions that were written for Java 1.3 work unmodified on the Java 1.6 beta.
Your statement is 100% false, face it.
Re:That's great... (Score:1)
you'll drop dead before you ever finish writing it.
Re:That's great... (Score:2, Funny)
I find it amusing that all of the people posting about their positive experiences with Java have user id's less than 50000, meaning they have been around here quite a while.
The trolls are all anonymously sprouting FUD
Re:That's great... (Score:2)
Because it's a ridiculous challenge, perhaps, and ignores a whole range of things that are actually more important? I've seen plenty of Java applications that do something useful in a mission critical environment, and there are no C/C++ applications for the sa
Re:People still use Java? (Score:1)
Re:People still use Java? (Score:2)
Re:C++? (Score:1)
Re:Too much work... (Score:2)
The code in javac is more than three times the size of my HelloWorld program, so I'm not sure it's compiling it correctly. Especially if Sun farmed out javac to some outfit in Bangalore. They won't care if it works. I'm scared to run my program now. What if it doesn't say "Hello World"? It might say "Goodbye world" and then delete