A Conversation with Chet Haase

---

One of the most popular presentations at last year's JavaOne conference was Chet Haase and Romain Guy's Filthy Rich Clients, demonstrating how far Swing can stretch to produce visually stunning applications. Haase, an architect with Sun's Java Client Group, has since written extensively on advanced Swing concepts, and is currently working on a book titled Filthy Rich Clients.

Artima interviewed Haase shortly after the final release of JDK 6, and asked him how developers can leverage new Swing and client-side Java features to create applications that look and perform on par with the best desktop applications. In this interview, Haase shares his views on why Swing defaults don't create good-looking Swing applications, AWT performance improvements, how applets can become part of a wider client-side ecosystems, and gives us a preview of his upcoming book.

Frank Sommers: What makes you most excited about new JDK 6 desktop and Swing features?

Chet Haase: JDK 6 is a pretty exciting release for the desktop overall. One thing we've been working on is graphics performance—you will see overall a big improvement in the performance of Swing applications.

JDK 6 also includes exciting AWT features for desktop integration. When people hear AWT, they probably think of the old GUI toolkit they're no longer using. However, as AWT is also the infrastructure Swing uses to talk to the native platform, AWT features actually mean Swing features.

AWT desktop integration features include a tray icon that lets you have something sitting in the system tray much as you'd do for native applications. There's also the ability to launch a browser to a URL from any Java application or, more generally, to launch a viewer for any particular file type that you have an application installed for on the system. You can even talk to your email client.

That sort of desktop native integration is key for Java. You want Java applications to behave just as other applications do on the system, and have access to all the desktop facilities.

In a similar fashion, we did work on 2D that includes the LCD text work. Fonts rendered in a Swing application now look on par with the native fonts. Native applications on XP and Vista and Mac OS X typically enable antialiasing for LCD screens, and now we have that capability for Swing applications as well. We detect the desktop property settings, and when Swing renders a window, the text in Swing uses a similar antialiasing algorithm used by the native system.

Plus, there are exciting developments in terms of the Swing API. Just to mention one, the API now includes SwingWorker that lets you write multithreaded Swing applications a lot easier.

Frank Sommers: A lot of development on Swing is now taking place outside the core Swing and JDK APIs. How do those external projects relate to what's bundled with the JDK?

Chet Haase: The external projects are breeding grounds for good ideas. When technologies developed in the context of those projects reach a point of maturity and robustness, or when they appear to address a core feature a lot of people need, it then makes sense to pull those technologies into the core.

A great example of this is SwingWorker that I just mentioned: there were various forms of SwingWorker around for a number of years that addressed an important feature that was not part of the core API: the ability to easily write multithreaded Swing applications. So in JDK 6, we made SwingWorker part of the core API.

Then there was work specifically done in SwingLabs, such as table sorting and table filtering. Those features had been talked about for years, but they didn't happen in the context of the core Swing APIs. They finally caught on in SwingLabs, and it made sense to fold them into the core.

The tray icon and desktop APIs that I alluded to earlier were from the JDIC project, and those features also went into SE 6. For a future release, we're looking at another JDIC project that provides the ability to embed a native browser into a Swing application.

Although many Swing components can already understand HTML, and Swing does have the ability to render HTML text, that still leaves you with fairly basic HTML support. In SE 6, we made it possible to launch an external browser. What people might want is a component that can actually display full-fledged Web content, and one way to do that is to use the native browser component. Then that component becomes part of the Java Swing application itself. That capability was developed in an external project, and we're looking into possibly folding it into the core Swing API in the future.

Finally, I should mention that I'm driving some work on animation that's also happening outside the JDK. Animated transitions allow you to connect the flow in an application in a more logical and obvious way to the user. The user can say, "OK, I did that, and now these results flowed in."

That contrasts with how most Web applications work today, especially pre-Ajax. If you type something into, say, a search box and press the "Submit" button, the entire screen is erased, and a new screen is drawn up with the results returned from the server. Those results may just be a lot of text, but the initial UI went away, and you got something different that you have to re-orient yourself to. Animated transitions not only make applications look better, but also make using applications more effective, because they provide a more natural transition.

The Future of Applets and WebStart

Frank Sommers: Many developers like the powerful Swing and client-side Java APIs, but loathe the possible problems users face when presented with WebStart applications or an applet. Compared with Ajax or Flex, installation of a suitable JRE seems to be client-side Java's Achilles' heel. What new JDK 6 features help address the deployment problem?

Chet Haase: We have been working on ease-of-deployment for a while. This is ongoing work. One of the technologies we introduced already in JDK 5 is called Auto-install. Auto-install automatically detects if, and what version, of Java is on the system. If the appropriate Java version is not there, it then starts an installation, based on a user agreeing to that installation. We're continuing to work on that technology to make it more cross-platform and cross-browser.

Some of the really important things seem silly from an engineering standpoint, but are important in making our deployment model more approachable. For instance, we had security dialogs pop up that would scare users during the deployment process, saying, in effect, "If you click on this button then all hell will break loose." We worked on simple UI issues around the security dialogs that pop up during the install process to simplify the experience for the user.

Frank Sommers: A lot of applications are accessed through a Web browser. When writing a user interface for a Web-based application, many developers think about Ajax or Flex to add interactivity to Web pages. What improvements are there in JDK 6 to make applets more viable?

Chet Haase: Applets are alive and well in a model they've always existed. What I'd like to see is more dynamic use of applets so that you can do what's right for your application situation.

Specifically, I'd like to see applets move in a direction where Java is a tool that can be chosen from a toolbox of many technologies. The past approach was that you either were using Java or not using it on the client. The Ajax model is interesting because people are actually using a mix of technologies, be that XML, CSS, all those Web technologies, JavaScript—whatever gets the job done. I would like to see Java become an important player there, not the exclusive or operation that it's perceived as today.

There are many things that make that possible already. You can toggle an applet's visibility, position, and dimensions on the screen dynamically, just like you can with some of those other Web browser technologies. You can have an applet interact with the DOM in an HTML page. You can have JavaScript call Java, you can have Java call JavaScript.

But you can go far beyond that. Suppose you have an HTML page displaying Flickr content and you want to edit an image. Doing that through Ajax ranges from difficult to impossible. Just given the transaction time to and from the server, the lack of interactivity—why not use Java for doing things where it's more appropriate, and where it's really effective?

I don't think we've done a great job telling people how that works and showing them how to use that sort of functionality in a straightforward way. And we want to figure out what we can do in the future to make that even easier. Are there things we could do to, say, make it easier to manipulate the DOM from Java?

Frank Sommers: In addition to ensuring the presence of the appropriate JRE, developers often complain about the slow startup time of applets. Are there solutions to that problem in JDK 6?

Chet Haase: We're continuing to work on that problem, that's not news to us. It turns out to be a fairly difficult problem to solve. There are no particular advances in JDK 6 around the startup problem, but there will be in the next release.

If you start looking deeply into the startup problem, the issue tends to be the startup of the first applet. We call that a cold-start problem, because that's basically the first startup of Java on the system since reboot. Most of that problem is embedded in an OS issue, such as bringing a lot of data into the disk cache. It has nothing to do with Java and class loading, it's all about how fast you can load the files into the disk cache and get them running.

If you've already run an applet in the browser, running another applet in the browser is just as fast as it needs to be. Even if you close the browser and bring it up again, it's still on the order of a second or less, which I think is reasonable in the Web space, where Flash, or HTML, or Ajax apps take about that much time to load. It's the cold-start that's really a non-starter for a lot of light-weight applets, and we're working to address that specific problem.

Building Great-Looking Applications

Frank Sommers: Let's talk a bit about looks. You've given several presentations on how to create great-looking Swing applications. When I compare your examples to a typical Swing application, there's a huge difference in look and appearance. While you are able to show stunning UIs, most Swing developers seem to have a hard time getting their applications to look even close to your demos. Why is it hard to make Swing applications look visually appealing, with UI effects and the like?

Chet Haase: I don't think creating nice-looking Swing applications is that challenging, but there are some basic approaches to Swing programming that aren't obvious to beginning Swing programmers. I don't think the tools today, especially prior to Matisse, made that any easier. If you just start with a blank canvas and a main() routine, what exactly are you going to do to make a beautiful Swing application?

If you write a Swing application with all the defaults, you get the basic Swing GUI look and feel, Metal, which will not make your application the best-looking one in the world. Our native look and feels have gotten a lot of attention lately, and can result in more professional looking applications that appear like everything else on the desktop. That's not obvious when you're starting out— because you need to know what API and system property is set to enable that capability.

Another topic that's very scantily documented is creating custom components. If you want to add more visual effects to a component, you need to know how to override the paintComponent() method. There are also high-level approaches to that. The components that come out of the box in SwingLabs, for example, get you a lot further in getting a better visual appearance for your application than just dropping into a text editor and typing in a Swing application from the start.

Another thing that contributes to a lot of Swing application look problems is improper use of threading. If you have a network-based application, and you're doing network or database accesses in the middle of your GUI thread, you cause your GUI to hang. That seems basic for people who have been doing this for a while, but it's a very common problem out there. The alternative, to do asynchronous accesses and progressively update the UI, is seen as tricker. Lately we've been trying to explain what the issues are, and to make it easier to create a reasonably performing application.

Working with Data on the Client

Frank Sommers: Ajax applications also need to fetch data remotely, but few Ajax developers have to be concerned about multithreading and updating the UI in the correct thread. Why does Swing make that task more complex?

Chet Haase: Ajax applications, by definition, always do things in the GUI thread because that is the only thread available in JavaScript. In contrast, Java lets you do anything you want on any thread, and has lots of powerful libraries and language constructs for dealing with threading issues.

While Java gives you all that threading power, Swing is a single-threaded toolkit that assumes you do things on a single GUI thread when performing GUI-related operations. So the trick with Swing is to know how to take advantage of Java's multi-threaded capabilities while obeying Swing's single-threaded constraint.

This might be easier to explain with an example. Suppose you're in some GUI application and someone clicks a button that causes a request for data from the back end. In Ajax, this might become an XmlHttpRequest, which typically proceeds asynchronously, and sometime later updates the GUI on the GUI thread.

The pattern for dealing with long-running requests off the GUI thread is built into this approach: The client code executes on the GUI thread, and the XmlHttpRequest is handled asynchronously on a separate thread. So the GUI is responsive while the data is being retrieved, and the GUI is updated appropriately when the data arrives.

In Swing, you have the option of sending your request directly from the GUI thread: you can call the server directly and get the data. But this would cause the GUI to freeze while the request was processed. It is far better to offload the request to a worker thread and update the GUI later, just like Ajax does.

Some confusion comes from the fact that there are many different ways of doing this, as opposed to the standard pattern established for Ajax applications with XmlHttpRequest. SwingWorker, available in Java SE 6, will help fix this problem and provide a standard way of performing this task.

Frank Sommers: Do you see Swing offering tighter integration with back-end technologies?

Chet Haase: An application with no data behind it is just a prototype. Developers are divided into a camp where you're either doing server stuff, or one that does client stuff. We have blogs, tutorials, and documentation that talk about those specific technologies. But connecting the dots between the client and the server is left up to the developers a little bit too much. I would love to see us tie into the back-end more. We can make that easier either through APIs, if necessary, and also via explanations of how to do something that may not be intuitively obvious.

There's been some work on that already in the context of SwingLabs where Richard Blair has been working on simpler access to Web services. I'd love to see more work there to enable end-to-end applications on a much easier scale than what is available now.

On the client, data binding is definitely an issue when working with data. You get back objects—strings— and have to figure out how to update your GUI appropriately. There are existing data binding frameworks for that now. Karsten Lentsch's JGoodies provides data binding, and there are others, too.

Similar to table sorting and filtering, this is one of those cases where we realized that all Swing developers will need data binding, and that it therefore needs to live in core. So there is a new JSR—JSR 295, Beans Binding—that will provide the capability of binding any JavaBean object to any other one. You can have a JavaBean object that represents the data source, and another bean that represents the GUI object, such as a slider. You can have the data affect the slider and vice versa.

Filthy Rich Clients

Frank Sommers: In closing, can you give us a preview of the book you're working on?

Chet Haase: I'm writing it with Romain Guy, and it's called Filthy Rich Clients. The title comes from a JavaOne session we did last year, which in turn comes from a phrase I like to use. We plan for it to be out by JavaOne.

The goal of the book is to explain the technologies and the process behind Swing, Java 2D, and AWT that allow you to understand how things work, and then to let you hook into that to actually make better-looking applications.

Swing is all about writing rich clients. Web applications and thin clients are totally appropriate for some applications, but as applications get more complex, as the data gets more complex, and as users have to use applications more and more, the richer you can make the interface, the better for the user—richer in terms of caching local data, in terms of presenting the data in a better way, local validation, as well as some of the things we focused on in the book. Animations, transitions, and rich graphics not only make applications more fun to use and more "cool-looking," but they enable more productive applications, and more productive users, because they keep the users more connected to the applications.

The book covers a lot of material, but starts with the fundamentals of how Swing, AWT, and Java2D work so that people understand the mechanisms and how they can plug into them to write these applications.

As we go about explaining how the fundamentals of animation work, we describe the animation framework libraries we provide to simplify animation. The entire last third of the book is about effects that are built using the concepts we discussed earlier in the book. The effects include static ones like shadows, spotlighting, and blur, and dynamic effects like fades, cross-fades, glowing, and morphing. All that sort of very graphically-rich stuff. There's also a chapter on animated transitions, with a utility library to make animating changes

Resources

Chet Haase's Blog
http://weblogs.java.net/blog/chet/

Chet Haase and Romain Guy's JavaOne 2006 conference presentation, Filthy-Rich Clients: Animated Effects in Swing Applications : TS-1297, 2006 (requires Sun Developer Network registration)
http://developers.sun.com/learning/javaoneonline/2006/desktop/TS-1297.html

Chet Haase and Romain Guy's Filthy Rich Clients demo source code
http://www.artima.com/forums/flat.jsp?forum=276&thread=176588

Filthy Rich Clients group on Yahoo Groups
http://tech.groups.yahoo.com/group/filthy_rich_clients

Romain Guy's Blog, Curious Creature
http://www.curious-creature.org

The SwingLabs project
http://www.swinglabs.org

Karsten Lentzsch' The JGoodies Framework
http://www.jgoodies.com

Talk back!

Have an opinion? Readers have already posted 3 comments about this article. Why not add yours?

About the author

Frank Sommers is a Senior Editor with Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.