•High-Medium priority have low false positive rates:effort was put into trying to ensure that issues reportedas high or medium priority correctness issues were issues that hada low false positive rate, and that developers would be interested inexamining all issues reported as high or medium priority correctnessissues, even in large code bases.

This line causes an Infinite recursive loop. This bug is high priority, in the correctness category.

returnsendMessage(user, body, null);

Can you find the Bug below ?

publicStringfoundType() {

returnthis.foundType();

}

Should be

publicStringfoundType() {

returnthis.foundType;

}

This is another example of an infinite recursive loop.This bug is found often in a decorator pattern when you forget to delegate to another method

Findbugsfound 5 infinite recursive loopsinJDK1.6.0-b13.Including this one written by Joshua Bloch

• Smart people make dumb mistakes

• 27 across all versions of JDK, 31 in Google’s Java code

• Embrace and fix your dumb mistakes!

Can you find the Bug?

if(name != null || name.length > 0)

Should be

if(name != null && name.length > 0)

thisnull pointer bug was found in com.sun.corba…

Can you find the Bug?privatefinal String _lock = "LOCK";...synchronized(_lock){...}

Constant Strings are shared (even private ones) across all other classes loaded by the JVM.This could lead to unexpected deadlocks in conjunction with other code. This bug was found in Jetty.

This null pointer bug was in Eclipse since3.2:

if(adapters == null && adapters.length == 0)

return;

•example of statement orbranch that if executed guarantee that a null pointer exception will occur

butin this case adapters is probably never null, that’s why it didn’t get noticed.

•somemistakes don’t matter much, because the impact of the mistake is minimal.

•null pointer exceptions usually get noticed. A harder error to find is that it won’t return if the length is 0.

Can you find the bug?

try{ ... }

catch(IOException e) {

newSAXException("Server side Exception:" + e);

}

The Exception is created and dropped rather than thrown, Should be :

thrownew SAXException("Server side Exception:" + e);

Can you find the Bug?

publicstatic String getNameById(String userId) {

String str = userId;

str.replace(' ', '_');

returnstr;

}

Ignores the return value of the replace() method, Should be:

str=str.replace(' ', '_');

A very common mistake is ignoring the return value on methods whose return value shouldn't be ignored.

• Strings are immutable, so functions like trim() and replace() return a new String.

What does this Print?

Integer one = 1;

Long addressTypeCode = 1L;

if(addressTypeCode.equals(one)) {

System.out.println("equals");

} else {

System.out.println("not equals");

}

It prints "not equals". According to the contract of equals(), objects of different classes should always compare as unequal

Incomparable equality:

•Using .equals to compare incompatible types

•Using .equals to compare arrays

•only checks if the same array

•Checking to see if a Set<Long> contains anInteger

•never found, even if the same integral value is contained in the map

•Calling get(String)on a Map<Integer,String>

•Returns false , not an error

These bugs may be hard to find on your own

•Types not always explicit

•May be introduced by refactoring

For example a Google refactoring changed a method to return byte[ ] rather than String

Bugs that Matter…

You can have mistakes which don't actually cause problems. Bugs that matter depend on the context. Not every bug found matters, but the effective use of Findbugs can remove bugs cheaper than with other methods

What is the best way to use Findbugs?

You want to find an effective way to use static analysis to improve software quality.5-10% of mistakes can be found with Findbugs, for some types of bugs it can find all of them.Testing and running code in production will find the bugs that matter, the bugs that cause problems .If you run Findbugs on code in production , then a lot of bugs have been fixed, if you run on new code your are more likely to find bugs. The reason to use findbugs is not to fix all your quality problems, but rather for the issues it does find, finding and fixing with Findbugs is cheaper than finding with testing or causing a problem in production.

•Use Findbugs on new code to remove bugs cheaplybefore bugs are detected using more expensive techniques

•The best time to have a developer look at a warning is when it is introduced,while the code is fresh in a developer’s head.

Expensive Mistakes are …

•Mistakes that fail silently

•Bugs that silently cause the wrong answer to be computed are the scariest bugs, because they will not be noticed easily .

•Mistakes that cause loss of money when they occur

•Mistakes that are hard to fix

Mistakes that matter ($$) can be found by testing or eventually in production, but it is cost effective to find bugs before testing and production with findbugs.

Runtime exceptions can be your friend…runtime exceptions can point you right where the error is

If a mistake causes a runtime exception, then the mistake will be foundand corrected .

Throwing a runtime exception is often a reasonable way to fail safely and report a failure.

This bug would have cost $ in production, but fixed at Google, within 30 minutes of being reported.

Can you find the Bug?

intvalue2;

Public booleanequals(Integer value1){

returnvalue1== intValue() ;

}

publicInteger intValue() {

returnvalue2;

}

Uses reference equality rather than .equals, should be:

Public booleanequals(Integer value1){

returnvalue1.equals(intValue() );

}

For boxed primitives, == and != are computed usingpointer equality, but <, <=, >, >= are computed bycomparing unboxed primitive values. This can bite you on other classes (e.g., String), but boxed primitives is where people get bit

Concurrency Bugs

•Inconsistent synchronization –

•a lock is held sometimes when field accessed

•Problems with wait/notify –

•e.g., call to wait() not in loop

•unsafe lazy initialization of static field

Can you find the bug?

synchronized(object) {

if (<condition does not hold>) {

object.wait();

}

//Proceed when condition holds

}

Should be:

synchronized(object) {

while(<condition does not hold>) {

object.wait();

}

//Proceed when condition holds

}

Use Java 5!simplified concurrency , less likely to make these mistakes.