V
Veloso
Sun's Java site, java.sun.com, has an interesting interview (http://
java.sun.com/developer/technicalArticles/Interviews/community/
harry_qa.html) with Brian Harry, a.k.a. the "bug guy," who talks at
length about how he fixes bugs. Harry, an independent consultant from
Iowa, 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."
Harry 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."
I'm just starting to look at the Swing code, which feels a bit
overwhelming. Harry advises that Swing hackers map out the
relationship between the Swing class and its UI and says that to be an
effective Swing hacker, you need to know what's coming from what.
Anybody with more experience have comments on all of this?
java.sun.com/developer/technicalArticles/Interviews/community/
harry_qa.html) with Brian Harry, a.k.a. the "bug guy," who talks at
length about how he fixes bugs. Harry, an independent consultant from
Iowa, 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."
Harry 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."
I'm just starting to look at the Swing code, which feels a bit
overwhelming. Harry advises that Swing hackers map out the
relationship between the Swing class and its UI and says that to be an
effective Swing hacker, you need to know what's coming from what.
Anybody with more experience have comments on all of this?