Java Performance Services
Training, Seminars, Benchmarking, Tuning

Java Performance Tuning Course


Chania Crete, May 17-20, 2010


Sun Extreme Learning EXL-2025

Houston, December 1-4,2009
New York, December 8-11, 2009
Washington DC, January 5-8, 2010



San Francisco, January 11-14

Anti-if

I have joined Anti-IF Campaign

Calendar

««Nov 2009»»
SMTWTFS
1234
5
67
891011121314
15161718192021
22232425262728
2930

Performance Anti-Patterns

My Top Tags

                                       

Mailing List

My RSS Feeds








FindBugs advice

posted Thursday, 23 November 2006
I’ve been looking at the FindBugs tool written by undergraduate students at the University of Maryland. As the name suggests, FindBugs scans your source code and look for things that at best, a compiler may flag as a warning or just complete ignore. What has impressed me about the tool is not that it caught so many problems in the code, it is the quality of the advice that it gives regarding what it found and suggestions on how one might fix the problem. For example, I had a couple of methods that returned null. FindBugs classified that practice as "Dodgy" and then offered up this advice.
Consider returning a zero length array rather than null It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method. On the other hand, using null to indicate "there is no answer to this question", then it is probably appropriate. For example, File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory.
Being someone who is focused on performance, my first thought was, now that is a good way to create a lot of extra garbage. But immediately following that thought came a memory from my days as a Smalltalk programmer. Smalltalk place holders (variables) are not typed. Now one may think that would lead to a whole host of problems but in practice, it didn’t. One of the reasons is that place holder names implied intent. Using names that implied intent suggested to developers which types of object should be assigned to the place holder. The contra positive of this is that developers tended not to assign unintended objects to the place holder. The fallout from this is that properly written Smalltalk methods should never return nil (or null in Java). The result was that code could be normalized or IOWs, written in such a way that you never had to worry about null pointer exceptions (in Smalltalk, since nil is an object, this would be a method not found exception). The take-away from this is that not returning null is actually consistent with the message that I give in my performance tuning course, good design and coding practices should win. In this case the lesson learned from Smalltalk still applies in Java. However it is a lesson that I had somehow forgotten. Thank you FindBugs!

tags:          




1. Mica Cooper left...
Sunday, 26 November 2006 5:29 pm

Hey,

LOL. I got tired of dealing with null returns a long time ago. Almost every method I return with, starts with the creation of a default 'blank' return object. If the method errs, I log an appropriate message and return the default. While this of itself can cause issues, staying on top of the error messages is the answer to that.

Mica