Janice J. Heiss's Blog

April 2007 Archives

The Bug Story

Brian Harry, a.k.a. the "bug guy," talks at length about bugs in a java.sun.com article by yours truly, Getting the Bugs Out: A Conversation With Bug Fixer Brian Harry. Harry, winner of a Duke's Choice Award, fixed Java SE 6 bugs numbering into the hundreds. His method: he scanned Sun's openly available bug database for intriguing bugs, primarily in the Swing user interface code, printed them out, and put the bug reports on a stack beside his computer. Then, he fixed them one by one, submitting them through the standard JDK Community contribution process.

The interview gives the details:

* He points out that fixing bugs is a great way to understand
how the code works. To James Gosling's bug rule, “If you don't
see the bug where you're looking, perhaps you're looking in the
wrong place.” Brian adds: "The place where you find bugs may not
be the right place to put a fix in".

* His basic advice: “First, always acquire the test that’s attached
to the bug report... Next, ask yourself if it’s really a bug... Also,
consider writing different solutions... As to writing unit tests, look
at what the patched code interacts with.”

* Swing tip 1: "Try to be comprehensive in testing the patch with different
LAFs (Look and Feels)."

* Swing tip 2: "Make sure that the test case is running on the EDT
(event dispatch thread). If it isn't, you may not have a bug, but
instead just have bad programming."

* "If you’re doing a Java code fix, don't just look at the current version of
the platform. I’ve routinely tested out bug tests on 4, 5, and 6 to investigate
when a problem started and stopped. See if you can find why something started."

IMHO, there's lots more of value. Have a look please and tell me what you think...

Sun's Java compiler tech lead speaks out

An interview, Meet Peter von der Ahé, Tech Lead for Javac at Sun Microsystems, I did with Peter, Sun's tech lead for javac, discusses the Kitchen Sink Language, the Java Compiler API, and new ways of thinking about generics, reification, type inference for local variables, and lots more. If you want to experiment with javac, check out the Kitchen Sink Language.

Peter has a lot to say:

-- Learning to use the Java Compiler API (JSR 199) "will provide a lot of
indirect benefits" to Java developers. Danny Coward commented: “For those
of you deafened by your screaming inner geek, roll up your sleeves and give
it a try."

-- Regarding generics: "Rather than trying to provide
reified types for all instances, why not simply accept that some
instances do not have reified type information, because they are
compiled with a 1.4.2 compiler, or for other reasons? This turns reification
into a best-effort problem: if you use a raw type, then no type information
is reified, but if you avoid raw types, you can take advantage of the additional
reified type information."

-- His proposal for an alternative to type inference for local variables
involves having the compiler provide the static factories.

Hope this triggers some interest.

This work is licensed under a Creative Commons License.