Meet Chet Haase, Java Platform, Standard Edition (Java SE) Client Architect at Sun Microsystems

Print-friendly Version

Bio: I'm a Java Platform, Standard Edition (Java SE) client architect in the Java Desktop Group. I work with engineers and managers to make Java technology on the desktop more productive, useful, and successful. This means tracking desktop application development in general and making sure that Java software meets and hopefully exceeds developers' requirements. My background is in graphics, 2D and 3D, so I tend to focus more on graphics-specific issues in general, such as performance and graphical effects for our GUI toolkits. I write about Desktop Java issues such as graphics, performance, and Swing effects on my blog.

java.sun.com: What project are you currently working on?

Haase: The first order of business is finishing our current release, Java SE 6. We are freezing for beta soon and anxious for people to try it out and give us the feedback that will help make the final release solid. But this time around, we've had development builds posted regularly for several months, so we're probably ahead of the game for a typical beta release.

At the same time, we are also planning for the next major release after Java SE 6, which entails looking at the features customers have requested and the capabilities that we think will be important in the time frame of that release.

One of my current development projects involves animation. The ability of GUIs to be dynamic is of growing interest, especially as simple animation effects are enabled by default on desktops such as the Macintosh and Windows Vista. So what can Swing do to enable these kinds of effects by default or to expose APIs that make it easier for developers to use and extend these capabilities appropriately?

It's important to add features that make sense and not go hog wild. I believe in a conservative approach to GUI effects, as opposed to an anything-is-possible approach. Most GUIs are still targeted at standard business usage, so you don't want to create a look and feel that confuses users. There is a fine line between rich user experience and ridiculous gratuitous effects.

JSC: What improves your skills as a developer?

Haase: Drink coffee -- especially strong Peet's coffee, which seems to bypass the stomach and go straight to the brain.

I also find that starting new projects occasionally helps get the juices flowing. I do this in the context of demos for articles or presentations, or projects for developing new capabilities for desktop development. The process of starting something new and having to develop it completely gets my mind out of the ruts that it's stuck in.

I also find that writing about projects improves them. For example, I'm currently trying -- desperately -- to finish a series of articles about an animation framework that I demo'd at the 2005 JavaOne Conference (in the first part of the "Advanced Java 2D" session). The framework was mostly functional four months ago, so all I had to do was describe it.

But in the process of describing it for external developers, I realized that several elements of the framework were not as good as they could be. Only after stepping outside of my code did I get a better understanding of how to improve it. It's still in process, but it's much better now than it was in June. I just hope that I can stop twiddling it and finish the articles soon.

JSC: What do you do when you feel stumped by a problem?

Haase: Two approaches have worked for me over the years.

(1) Quit. Put the problem away and work on something else. I think the mind keeps churning on interesting problems regardless of what you want it to do. I always remember the take-home final for a class in computer science theory in grad school. There was one problem that I just couldn't get, no matter how I tried. Then I woke up in the middle of the night and suddenly had the answer. I wasn't programming in my sleep. I just forgot about it for a while and did other things, and the answer finally worked its way into my mind.

(2) Mooch. Discuss the problem with peers. Sometimes in the process of explaining it, you come to a better understanding yourself and might actually derive the answer in the course of the conversation -- resulting in a "Never mind!" to the people you dragged into the discussion. And if you don't come up with the answer yourself, your peers may be able to help you.

JSC: Can you name some things you wish you'd learned in engineering school?

Haase: I actually could name lots of things I learned in engineering school that I wish I hadn't wasted my time on, but I guess that's not what you're asking.

One big difference is that you work on new and small projects in school and huge and old projects in the real world.

For example, the code I work on at Sun is part of the JDK library that has been in constant development for well over 10 years. Frequently, the hard part of any fix or feature is not the functionality of the fix or feature itself, but rather how it integrates with all of the code around it. Does the fix break compatibility? Does it conflict with anything going on around it? Do you understand the context of the code? This is something that's particularly difficult in old code bases in which the original developers have all left long ago. Does your team agree with and understand the changes?

I don't know how to cover such topics in school effectively (especially in the tight time frames of individual classes), but the more students are exposed to team development, versus individual projects, the easier it is for them to become integrated into team development in the real world.

Related to team development, I think code reviews would be a great tool for school. I've probably learned more about coding practices and the code I work on through the reviews we do in the client group than in coding itself. You learn how others do things, you get objective perspectives on how you do things, and everyone comes to a shared understanding of how teams should develop common code.

JSC: What are the most interesting changes that you have observed in software over the years?

Haase: I'll answer a different question here: What is the most interesting thing that hasn't changed in software over the years?

The most fascinating thing about software, and the thing that probably continues to make it an interesting field to work in, is how nondeterministic and problem-fraught the development process is.

Everyone thinks of computers -- hardware and software -- as being these dry things that always do what you tell them. But both are created by humans, so errors are introduced, unexpected behaviors result, and computers end up being very nondeterministic as a result. You would think that after half a century of software technology, we would be able to write software with fewer bugs, but instead, we write increasingly complex software with increasingly complex bugs.

I find it interesting that this problem hasn't changed over the years. But if software development became a deterministic science, where the chance of bugs and unexpected behavior was nonexistent, it probably would also be devoid of creativity and intensely dull. And I wouldn't be doing it for a living.

JSC: Where in the process of programming do you have the most fun?

Haase: I live for the times when I see the initial results come up on the screen. One of the reasons I'm a graphics geek is that I find it so satisfying to see the pixels on the screen that result from the math and algorithms in my code. When you see the pixels, you know that something's working, and when you see the pixels in the wrong place or color, you know that something's not working. There's a cheap thrill from seeing the initial output from a prototype that tells me, "It's going to work!" Of course, the prototype took a half-day, and the real solution might take another month, but the best part is just seeing that it'll work eventually.

JSC: When are you most creative?

Haase: When I'm working off the Net and I don't have email constantly coming in requiring my attention. Email is a drug: It should be limited or even prohibited. It's like nicotine or caffeine -- it may not make us psychotic when we're on it, but it's incredibly habit-forming.

JSC: Can you describe how you write code?

Haase: This process differs from person to person. I've known people (especially people who write software development books) who write a complete design before starting to code. I've known people who start with the code and write it from start to finish.

I take the prototype approach. Maybe it's insecurity or a need for quick gratification, but I am never confident of a particular approach until I've gotten the main elements working in some simple way first. So I start out writing ugly, hacky code that just gets the basics working.

Once I've convinced myself that the approach will work, I step back and do the design and start writing better code. I read an interesting approach to this in Steve McConnell's book Code Complete. The trick to prototyping is to throw away the initial code and start afresh, to avoid any leftovers from that initial ugly prototype code.

JSC: What is the Java class that you couldn't live without?

Haase: java.lang.System. Without it, how could you issue a simple println() to debug your application?

JSC: If you could work on a dream project, what would it be?

Haase: I'm already doing it: integrating different media types in a graphical library and figuring out how to enable more effective and performant user applications. How could it get better than that?