 | |
JSC: What's the biggest misconception about the Swing toolkit? Hickey: I've been hearing for years that Swing is slow -- I think that's just plain false. You can write a slow application in just about any toolkit. Swing is very powerful, so it's possible to get lost. But you can write first-rate Swing applications that are very quick and perform well. For example, you can create animations that fade in and out. You can't do that on a lot of native toolkits. Swing allows you to do this fast. Even in Java 2 Platform, Standard Edition 5.0 (J2SE 5.0) and J2SE 1.4.2, you can create such animations. Writing Code
JSC: Can you describe the process of writing code? Hickey: I tend to have a lot of energy, so if I'm really excited about solving a problem, the first thing I do is quickly throw together methods and prototype it until I get the right bits on the screen or the right behavior. That's my proof of concept. It might take an afternoon or a couple of hours. But once I've proved that it works, I start thinking about how to properly design the API. Working on a toolkit team, or anywhere in Sun, we're writing code for others to use, so we have to think about creating the right API. Once we have committed to it, we can never pull it from the JDK. So we design it with developers in mind. There's a big difference between making it work really quickly for me and actually designing it flexibly. There's a lot to consider. When I'm prototyping functionality for large projects, I often take a step-by-step approach, writing small pieces and then building on top of them. For example, let's say I want to write a drag-and-drop application that allows you to drag an icon around on the screen. I first put together the drag-and-drop support that moves bogus objects. Then I see if I can drag a specific icon such as a red rectangle around the screen. Next, I see if I can get an image to move around the screen. Then I write the code that generates the image. I find the process quite exciting, and I'm always eager to get to the next piece of the puzzle! JSC: Where in programming do you have the most fun? Hickey: A lot of what I do is fun because I see instant results on the screen. When I fix a button to make it look more like Microsoft Windows or the GIMP Toolkit (GTK+), I see it instantly. I don't have to write a lot of test cases to sort data and make sure they print out correctly. The fun part is in the proof of concept. Sometimes in the middle of the night or in my morning shower, I'll get an idea. I used to have to wait 45 minutes to commute to the office, but now, working at home, I can run into my office and write it down or type in my ideas. JSC: Does an idea always work when you have these inspirations? Hickey: No, sometimes I have to revise it. It always gets me energized and ready to dive in. But sometimes the inspiration leads to new hurdles. So I go back to the mental drawing board and head down the hall to bed, to brush my teeth, or to play with my kids -- waiting for the next idea. A Compatibility API
JSC: If you could work on a dream project, what would it be? Hickey: As an engineer, I'd love to be able to clean up old and unused parts of the Swing toolkit and the Java programming language without having to worry about backward compatibility. It's just a dream though, because compatibility is very important to our customers and is something we take seriously. For instance, every time I fix a bug, even if I'm correcting completely wrong behavior, I must be careful not to break something for someone who is relying on that wrong behavior. For example, I modified Unfortunately, within a couple of weeks, two bugs were filed
against my change. It turned out that modifying the focused row
fired events, and some existing client code wasn't prepared to deal
with these events. Although I strongly want code to "do the right
thing," I understood that we must try not to break existing code.
Unfortunately, I had to pull this perfectly good code in favor of
something less optimal. Now, the focused row always stays at
The Swing toolkit team is considering creating a compatibility
API to deal with issues of backward compatibility. Such an API would
offer the "latest and greatest" to developers who are less concerned
with backward compatibility, such as developers writing new
applications or those new to the platform. The compatibility API
would enable me to protect fixes like the one in which I modified the
JSC: When will the compatibility API be ready? Hickey: I think with Java Platform, Standard Edition 7 (Java SE 7). To date, we've added properties to turn on pieces of behavior. But the compatibility API we are considering would allow the developer to turn on all of the protected improvements and fixes in a group, based on levels. For example, they could say, "Give me all fixes up through Java SE 7," or "Always give me the latest and greatest." We considered it for Java SE 6, but we weren't sure what we wanted to include. One example we'll probably include is control over font boldness in the Swing toolkit's cross-platform look and feel. The current look and feel uses bold fonts, something toolkits tend not to do any more. We've added a property called Class Favorites
JSC: What is the Java class you could not live without? Hickey: This goes back to my passion for drag and drop.
Some classes are central to the drag-and-drop experience, so for me,
JSC: What is your favorite Java technology book? Hickey: Working on the Swing toolkit, I don't read a lot of books about Swing or Java software any more. But two books do come to mind. When I first joined the Swing toolkit team, I learned most of what I know about Swing from either looking at the source code or reading The JFC Swing Tutorial, written by Kathy Walrath and Mary Campione. Even today, when I'm investigating a new Swing area, I refer to it. My other favorite would be Effective Java by Josh Bloch. JSC: Almost everyone says that. What is it about Effective Java? Hickey: The guy's brilliant! And he's extremely knowledgeable about common patterns and gotchas. I recently used the book to aid in a bug fix. I got stuck trying to figure out how I could provide a proper implementation of the equals method to a class and an extended implementation to its subclasses, without violating the equals specification. I started to get the feeling that what I wanted wasn't possible, and so I checked to see what Josh had to say in Effective Java. Luckily for me, he thoroughly covers the equals method in his book, including the exact problem I was trying to solve. I was right: I couldn't do what I wanted to do. But it's so nice to get validation from Josh's book in complete detail and in such an easy-to-understand manner. JSC: What do you do when you feel stumped? Hickey: Sun is full of brilliant engineers. So if I'm stumped, I can make a phone call, send email, or ping someone with instant messaging. There's always the Javadoc tool too. Working within the Swing toolkit, I've learned to pick up things from source code. And if it's completely outside the Java technology arena, I use the web. See Also
Shannon Hickey's Blog
| ||||||||||||||
|
| ||||||||||||
Print-friendly Version
