 |
|
Bio: William Pugh, who received a Ph.D. in Computer Science (with a minor in Acting) from Cornell University, is currently a professor at the University of Maryland, College Park. His accomplishments include the invention of skip lists, the revision of the Java Memory Model (JSR-133), and the development of FindBugs, an open source static analysis tool for finding coding defects in Java programs. He currently serves as the Spec Lead for JSR-305, Annotations for Software Defect Detection. You can read more about him at his blog.
|
Q: How do you feel about the open sourcing of the Java platform?
A: I'm exceptionally pleased. I've been telling Sun for years that they should open source the Java platform. I think this will be great for groups and researchers doing experiments with variants of the platform. I don't expect any serious development to be done in forks of Sun's JVM, but I hope that some of the innovative ideas generated by open sourcing find their way back into the main branch.
Q: How can you improve software quality with static analysis and the open source tool, FindBugs?
A: Improving software quality is a hard, multifaceted task. Doing it with static analysis is a thin but broad and useful piece of it. Static analysis tools look at a program without running it or requiring any test data or domain knowledge. Instead, they simply look for coding patterns that are likely to be bugs. An example would be invoking toLowerCase as a String and ignoring the return value, thinking that the method modifies the String it is invoked on. You can also look for places where a null pointer is likely to be dereferenced.
Until recently, tools such as FindBugs were thought to either generate useless warnings about proper code or to require tedious and painful annotation with formal preconditions and post-conditions.
The FindBugs project has found that numerous programming mistakes made by even great programmers can easily be detected with static analysis. So we've been very effective at finding quality "low hanging fruit," and lots of companies and projects have incorporated FindBugs into their development process. Google now runs FindBugs nightly over their entire Java codebase and is working to incorporate it into Mondorian, their system for reviewing code changes prior to commits.
As many quality-related tools, static analysis is subject to diminishing returns. As you try to push it from catching the obvious bugs to removing most or all bugs of a particular kind, it becomes harder and harder. If itÂ’s essential to exclude particular bug (for example, that no SQL injection bugs exist in your code), then you can use fairly detailed and sensitive techniques, but these analysis techniques are more difficult to implement and tend to require more developer time as well.
Q: What is the biggest misconception that Java developers have about maintaining software quality?
A: That talented developers using a good process automatically generate quality software. Mistakes happen, no matter how good the developers or processes are. If something is not being checked on a regular basis, the odds are that it will occasionally break. And even expert developers make stupid coding mistakes, and security experts make stupid security mistakes. Many of these "learning experiences" have been ones we've experienced with our own code.
Thus, I've learned, as much as possible, to try to use automatic tools that "have your back". Unit testing, output validation, and static analysis tools for both quality and security are all part of that.
Q: You are the Spec Lead for JSR-305, Annotations for Software Defect Detection. Tell us about it.
A: Static analysis tools like FindBugs don't really know what your code is supposed to do, so they can't check to see if your code is correct. Instead, FindBugs looks for something "obviously dumb" in your code. These tools could produce better results if they understood more of the design of your code. One clear motivating example is to allow you to describe which method parameters are allowed to be null and which ones are not. Another example is to allow you to mark which methods should never be invoked as though they were a procedure, ignoring the return value (for example, String.toLowerCase()).
Both FindBugs and IntelliJ defined Java annotations for nullness, but we used different names, with slightly different semantics. It was clear that no one was going to annotate their code with two different sets of annotations for nullness, so we needed a JSR to develop a standard set of annotations for expressing these issues that could be interpreted by multiple tools.
As we worked on it, we developed some interesting ideas for defining meta-annotations that would allow anyone to define their own annotations that could be interpreted by tools such as FindBugs. Like a lot of JSRs, it hasn't progressed as fast as I had hoped. We have a rough design sketched out, and we hope to have a preliminary implementation complete by the end of the summer.
Q: You are working with Joshua Bloch on a session on Java Puzzlers. How have Java Puzzlers helped you as a developer?
A: The two biggest things I get out of Puzzlers are thoughts about"great mistakes in language/API design," and new bug patterns to look for with FindBugs. I've always tried to make FindBugs find as many of the issues behind the Programming Puzzlers as possible, and this year I was able to take a couple of important bug patterns and turn them into puzzlers. As a result, FindBugs is able to diagnose all of the puzzlers this year.
Q: You have a minor in acting. Has that helped you as a developer?
A: Having experience in acting helped me learning to improve and be more comfortable with my presentation skills. That in turn has helped me a lot as an educator and communicator, which is an important part of being a developer.
Q: What online resources do you use to keep up with Java technology?
A: I get most of my updates from the Java Posse, cafeaulait.org and java.net.
Q: What advice would you give to a programmer new to the Java programming language?
A: Use an IDE (do you still have to say that?), read other people's code, and if you don't know how something works, try it.
Q: What is your favorite Java ME-enabled device?
A: I wish it was going to be an iPhone.
Q: The Java class that you couldn't live without is...?
A: java.lang.Object? But that really sidesteps the question; there are dozens if not hundreds of classes without which you couldn't write anything.
The class that most changed the way I write software is Map. It really is the Swiss army knife of Java programming. You get so used to it you don't think about it much, but I remember back to my (pre- STL) C++ days, and having Map is a fundamental change.
Q: What is your favorite obscure Java feature?
A: The "-target jsr14" flag to javac. FindBugs is designed to run under J2SE 1.4 (some people still seem to be stuck there), and -target jsr14 allows us to write FindBugs using J2SE 5.0 language features and still generate code that runs under Java 1.4 (so long as we avoid using any APIs that are only subsequent to J2SE 5.0.)
Q: Favorite Java book?
A: Although I really appreciate Joshua Bloch's books, I'd have to pick Head First Java as my favorite Java book, because it really helped inspire me to think about new, non-traditional ways of teaching software development to students.
Q: What do you do when you feel stumped?
A: Step away from my computer.
Q: What's the next big technology revolution?
A: In terms of impact on Java developers, ubiquitous multicore processors. In several years, most laptops and desktop machines will have at least 4 if not 8 cores, and helping people to develop software that makes effective use of those resources will be a huge challenge.
Q: If you could work on a dream project, what would it be?
A: The nice thing about being a professor is that you don't need anyone's permission to work on your dream project (although getting additional resources for your work can be a challenge). My next dream project is helping people write and test concurrent software, and I have a session talking about some of that on Thursday (TS-2220: Testing Concurrent Software).
Q: Where in the process of programming do you have the most fun?
A: When it seems to work, I'm comfortable believing that it works, and I can stop programming.
|
