 |
|
Bio: Sun staff engineer Ethan Nicholas is a member of the Java Deployment team that works with various technologies to improve the delivery of Java technology to end users. Ethan was the original lead developer behind Yahoo! SiteBuilder, a Swing-based web design application which powers over 250,000 web sites worldwide, and the open-source XML user interface language JAXX. You can read more about him at his blog.
|
Q: The most important thing for Swing developers to understand is...?
A: Don't do I/O in the event dispatch thread! I/O operations can block for an arbitrarily long time, and blocking the event dispatch thread causes your program to become completely unresponsive. Even if you are aware of this and are careful about it, it's surprisingly easy to do it by accident.
For instance, if you're painting a component which contains an image, the image itself might not have been loaded from disk yet. In this case, your image management code retrieves the image. But if this occurs during painting, and thus, in the event dispatch thread, your program will remain unresponsive until the entire image is read from disk (or the network!) and processed.
To ensure that your program remains responsive, prefix all of your I/O code with an assert that ensures that you are not in the event dispatch thread. You might be surprised by how many times you manage to trip the asserts.
Q: What recent changes to the platform have made your life easier?
A: I'm a big fan of the language changes in Java 1.5, particularly Generics and Enhanced For Loops. Unfortunately, I am often constrained to working on earlier versions of Java, which makes me appreciate the new features even more.
I find generic types so helpful that I use them often, even when they are not supported. For instance Java 1.4.2 does not support generics, so I instead use generic-inspired comments:
List/**/ names = new ArrayList/**/();
There are two benefits to such comments. First, as with real generic types, they make it easier to browse the code and find what kinds of objects you are dealing with. Second, when I am able to move to a newer version of Java, converting the code to use generics will be a piece of cake.
Q: Favorite Java book?
A: I started using Java when it was first released, before there were any real books for it. I read the Java Language Specification, the Java Virtual Machine Specification, and the API JavaDocs, and then I dove in and started writing applets. I was still in high school at the time, so I didn't exactly have much of a library budget in the first place.
Since this trial by fire, I have continued to use the Javadocs and other online material as my only real references. Aside from the official specifications, I've never actually read a book about the Java language.
Q: What do you do when you feel stumped?
A: I double-check my assumptions. When I'm truly stumped -- when I'm sure my code is correct but for some reason it still isn't working—I try to think of everything that I am taking for granted. For instance, I'm assuming that the binary code I'm testing accurately reflects the source code I'm editing. I'm assuming that the underlying APIs are working properly, that my Java installation is correct, that my operating system is working properly, and so on.
Almost invariably, one of these "safe" assumptions will be incorrect. Perhaps I've accidentally been editing the wrong copy of the file so my changes aren't being incorporated, or perhaps the build script is failing to recompile a file that has been modified. It could be a bug in the underlying APIs, or the operating system, or even the hardware.
The most important rule is not to take anything for granted. Anything you take for granted without checking could be where the bug is hiding.
Q: What aspect of programming is the most fun for you?
A: I have the most fun during the early stages of a project. You imagine the finished project, you lay down its outline, and then you start filling in the details. You can very quickly get the project to lookfinished as in most of the features are there, and it all seems to work fine as long as you don't breathe on it too hard.
The problem is that a program which looks done might only be 10% completed. Have you added all the hard features, dealt with all the nasty edge cases, added all the user convenience features such as autosaves, backups, and recovery of damaged documents? There are probably tons of bugs, many of which are going to be hard to find and fix. Such issues might go unnoticed during a brief scripted demo, but they could render the program totally unusable.
Sadly, even though this stage is the bulk of the project, it's also the least exciting part, at least for me. Developers can spend months implementing these important-but-unexciting features and dealing with edge cases that 99% of users will never encounter. It has to be done, but it's not exactly glamorous work. I prefer the beginning part of a project, before cold hard realities intrude.
|
