The previous entry featured an interview with Romain Guy, the co-author of the “Filthy Rich Clients” book. Today it’s time for Chet Haase, the second author behind this book.
Why have you decided to write this book?
I’ve wanted to write a book for some time – something in the general area of Java and graphics. Then when the idea came up or Filthy Rich Clients, it all made sense. Maybe all I needed as a catchy title?
This is your first book. Looking back, is it easier or harder than what you thought it would be?
Hmmm – mixed.
Actually, the writing itself went better than I thought it would. It turned out that Romain and I could produce lot of content in a relatively short time, and we enjoyed doing it.
But editing the book was quite different; it was sheer hell and torture. Specially painful was the part where people whose opinion you respect review the material and tell you everything that you’ve gotten wrong. It was a dark and depressing winter.
Are you happy with the way the book turned out to be?
Very happy. I think there’s a nice mix of fundamentals, telling people the way things work inside Swing and Java 2D, and very fun stuff, showing how far they can take the platform to create cool applications. There are lots of demos to illustrate the points, lots of pictures to show how things look, and lots of footnotes to help pass the time and fill in all of that empty space at the bottom of the pages.
What is your favorite chapter and why?
Actually, I’ll choose a whole section and not just a chapter:
Part IV: Effects.
All of the material in this section was the original inspiration for the book – let’s show developers how to do the cool stuff for their applications. The rest of the book is all about showing how everything works so that you can understand the Effects section completely when you get there. It’s one thing to just copy & paste some demo code, but it’s much more powerful to be able to understand how it all works so that you can go write your own custom effects.
Jokes on “this is not a book on binding” aside, do you see the business developers adopting the techniques you’re explaining in the book?
Absolutely. I think that any application (perhaps especially some of the truly awful ‘enterprise’ applications that I’ve had to use) could benefit from a better user experience. The effects we discuss in the book are all about enabling better user experience.
For example, the techniques outlined in the Animated Transitions chapter are about creating a seamless flow in an application and avoiding the Submit-Erase-Repopulate UI experience of most web applications today. These techniques could apply just as well to a typical forms-based application as to a more consumer-oriented application.
Using effects is not about animating and jazzing up anything and everything arbitrarily in a user interface; they’re about using the right technique to achieve the goal and improving the experience of the user to make them more productive in using your application. And heck, maybe your users will even like your application more in the process.
Have you thought about adding tooling support (for example in NetBeans) for the TimingFramework?
I would love to see tool support for creating animations in general, whether it’s a tool for creating animated applications or just adding animated effects to a standard GUI.
The original goal of the Timing Framework was not just the library itself, which is just about the plumbing details of running timers and interpolating values, but to help make animations easier in general. I can envision other libraries layered on top of the Timing Framework to make animated effects easier, or component animations easier, or animated transitions easier. And then on top of these, we need tools to make it all dead simple to all developers.
Are you planning on writing more books on desktop technologies in general and on Java desktop in particular?
It’s entirely possible. I’d like to find the intersection of material that the community would like to read and technology that I would like to write about. Specifically, are there other graphics-related topics that warrant a book? Or maybe just one on Java Jokes?
What are your top three wishes for the desktop APIs for the next JDK release?
Animation, performance, and animation.
What are the top three desktop APIs that you wish never existed in the JDK?
Do I have to limit this to desktop APIs?
First on my list is whatever set of classes with ALL_CAPS names. I think the culprit is Corba. I spend a lot of time with the JavaDocs, and I sure am sick of seeing all of those CAPITALIZED classes screaming out at me from the list of all classes.
Next would be PixelGrabber, which tends to be a common way (still!) that people use for getting at the pixel data of an Image. If only we had created BufferedImage in 1.0, then there would have been a far easier and faster mechanism for getting that data.
Finally, I’ll pick on Image.getScaledInstance(). It’s just too horribly slow to be useful, but many people still use it because it’s probably the most obvious route to quality down-scaling in the API. Check out the Images chapter in the book or Chris Campbell‘s excellent article on java.net for the nitty gritty details on how slow this method is and what better alternatives you have.
Do you see yourself in Java desktop area in five years?
Sure! You can never tell about this stuff, but it’s clear that I’ll be fooling around with pixels somewhere. If it’s not related to graphics, I’m probably not interested.
Would you take this book with you to a deserted island?
I think not. After writing, re-writing, and editing the entire book several times, I’ve probably read it enough for several lifetimes. On the other hand, perhaps it would help me pay for passage on a rescue ship. Also, at something like 550 pages, the book would probably help provide some starter fuel for campfires.
Would you take Romain with you to a deserted island?
And then leave him there? That would be cruel, but it’s worth considering.
Besides, Romain loves dessert, so I’m sure he’d love a dessert island.
Does Romain have a good taste in food, or is it just a stereotype on French people?
He eats more American junk food than anyone I know. So either our junk food is of very high quality, or the French palate is highly overrated. Or maybe he’s not French and he’s just been faking that accent this whole time.
With the “Filthy Rich Clients” book just around the corner, the co-author Romain Guy was gracious enough to answer a few questions that i had about the book and the related topics.
Whose idea was it to write the book?
Chet came up with the idea. Chet loves to write and his wordy, yet, rare, blog entries are a good giveaway. That Chet wanted to write a book seemed quite natural to me. Because I also really enjoy writing, I translated a few books for O’Reilly and wrote a couple hundreds articles for technical magazines, Chet offered me to co-author the book. Besides, our skills are very complementary. Chet takes care of the technical groundwork and the jokes while I handle high-level effects and visual stuff. He knows how to write code, I know how to use Photoshop.
How much time did you spend on writing your part?
It’s hard to come up with a precise answer. My writing spanned over about 4 months, during which I was quite busy with school and exams. I spent long periods without writing anything and did most of the work in short but intensive bursts. That’s how I always worked but it drove Chet insane. He was quite worried at times but we delivered in time.
Did you use any special collaboration tools on those chapters that you wrote together?
Unfortunately, no. I have used Subversion and CVS in the past for that kind of work, but we relied entirely on Word’s tracking system, IM (a lot) and email (gazillions of emails were exchanged.) We did not bother much with collaboration tools because we worked separately on chapters. Only chapters 2 and 5 contain text that we both wrote. However, I was worried about losing work when trying to merge the files we exchanged by email. Actually we made a mistake once and almost lost a bit of work; good thing I have two daily external backups. And I know that for our next book we will use plain text and Subversion.
How did you decide on what goes in the book and what stays out?
That’s quite easy. Everything went into the book, nothing stayed out. As I said earlier, Chet and I are quite experienced writers. Besides, we thought hard about the content before starting writing the first pages and it was very clear to use what the final content would be. We did shuffled chapters around but we didn’t have to suffer from any cut or large addition.
How did you handle the inherent restrictions of the printed format for such a dynamic area as animations?
One of our recurrent jokes was to print an animation’s frames in the corner of the pages and use the book as a flip-book. From the beginning we knew that the book would have a companion site with all of the source code. We also simply decomposed a few animations as a series of screenshots or diagrams in the book. While it doesn’t look as good as the real animation, it does an excellent job at showing precisely what happens on screen.
Do you see value in writing books in the blog era?
I definitely do. Even though I spend a lot of time every day reading blogs and online articles, I always find it tedious to read on a screen. Blogs also tend to focus too much on details or, on the contrary, do not delve enough into the details. This is very valuable but a book is always, to me, a better asset when I need to learn about a technology or a topic I know nothing about.
I know that glass panes were your favorite technique once. Has this changed?
I would say that my favorite technique was and still is @Override protected void paintComponent().
What are your top three wishes for the desktop APIs for the next JDK release?
I am pretty happy with the APIs as they stand now. That said, I’d love to see non-rectangular windows, lightweight/heavyweight integration (which would bring video, 3D and 2D together) and something like SwingX‘s painters.
What are the top three desktop APIs that you wish never existed in the JDK?
One is obvious, AWT. Just because I’m tired of explaining on forums that you should not use Canvas and Button but JComponent and JButton. And it has nothing to do with Java, but I have a profound dislike for Tk and wxWidgets APIs.
What other non-Java desktop toolkits do you use? What can Swing learn from them?
I used Tk, wxWidgets and QT quite a lot in the past. I am particularly fond of QT, even though it’s far from perfect. Nowadays, I also enjoy working with Cocoa. The interesting thing about those toolkits is very often the ease of use. Their architecture is not always very pretty but you can get things done with them very quickly and they are easier to apprehend. I don’t think Swing could learn anything from them since it’s too different and too complex now. However, Sun could learn from them for a possible new toolkit; it’s all about ease of use and making common use cases easy to implement. Desktop Java developers could learn from those toolkits. For instance, I am fond of Cocoa developer’s use of images. Instead of tinkering with drawing APIs for hours to create a nice looking widget, they just stitch a few images together. It’s simple and efficient.
Would you take this book with you to a deserted island?
No, I’ve read it so many times that I know it by heart now.
Would you take Chet with you to a deserted island?
Only if I can also bring a typewriter to keep him busy and prevent him from telling me his jokes.
Do you actually like Chet’s jokes?
I actually do like them a lot!
Over the past two weeks i have presented a few solutions to paint validation overlays in Swing. The sheer variety of the solution spectrum serves to highlight the extensibility of the Swing painting pipeline.
As can be seen from even such a simple example as validation overlays, there are many ways to achieve the desired functionality in Swing, each one having its advantages and disadvantages. This variety is, perhaps, Swing’s biggest blessing and biggest curse. On one hand, if you know how Swing works, you can achieve almost everything. On the other hand, if you’re a novice developer, it’s just too much to handle.
In addition, you need to be fully aware of the limitations of each technique to choose the one that best suites your needs. There is no single silver bullet that works best for all requirements, and in most cases the best solution would be a combination of two or even more working together. Hopefully this series has helped you put a few more tools in your developer arsenal. So the next time you need to provide some custom painting functionality, look at the Swing painting pipeline, weigh all the options and go with the one that would work best for your specific requirements.
To sum up, here are the links to all the entries:
- Repaint manager
- Overriding paint() manually
- Using AOP to override paint()
- Custom border
- Layered pane
- Glass pane
- JXLayer
- Extending look and feel
- Multiplex look and feel
Perhaps one of the bigger disadvantages of implementing the validation overlays by extending a specific look and feel is that this technique effectively locks your application into that LAF. While this can be addressed with complicated bytecode injection techniques that might fail under different LAFs, isn’t there another way to add the validation overlay as a simple “add on” on top of any LAF? In this entry we will look at a solution available in the core Swing package – a multiplexing look and feel.
Available from as far back as JDK 1.3, the MultiLookAndFeel class sounds like a perfect solution to our problem. Reading the documentation of this class promises a nice and clean solution:
A multiplexing look and feel [addresses] both these problems simultaneously because it allows multiple look and feels to be combined. The first problem (having to use what amounts to a second copy of the same code) is solved because the developer can create a specialized look and feel that can then be combined with other look and feels. The second problem (having to force the use of a particular look and feel) is solved because a specialized look and feel can be used with whatever default look and feel the application may have locked in place.
With all this promise there are surprisingly few examples of using multiplexing LAF (even given that it has existed for quite some time now). First, you can read this thread on java.net dating back to 2005 (especially the remarks from then-Swing architect Scott Violet). Second, note how this bug is still open after two years. In this entry i’m going to show just a few deficiencies of the multiplex LAF implementation and why you should stay clear of it in most cases.
The classes in this entry are located in the org.pushingpixels.validation.multilaf package and implement the validation overlays using a multiplex LAF (on top of the Substance LAF). The first implementation takes off by learning all the mistakes from the previous entry – using custom borders and special handling of inner text fields for proper overlays. The ValidationTextFieldUI and ValidationComboBoxUIFirstTry do just that. Then, we set Substance as the “main” LAF and add our “validation” LAF (that has these two UI delegates) as an auxiliary LAF (you can have more than one). Here is how our application looks like:
As you can see, the combobox buttons are clearly not coming from the main LAF. What is going on? Our combobox UI delegate extends the BasicComboBoxUI (so as to allow us to add the validation overlay functionality to any LAF). The arrow button is part of the internal implementation in the UI delegate and is created by the createArrowButton(), which is called from the installComponents(). So far so good, since this is how a combobox UI delegate that extends the basic implementation works. The problem with the MultiComboBoxUI is that it invokes the “lifecycle” methods of the installed UI delegates starting from the main LAF. And so, the MultiComboBoxUI.installUI first calls SubstanceComboBoxUI.installUI (which calls SubstanceComboBoxUI.installComponents which calls SubstanceComboBoxUI.createArrowButton), and then calls the ValidationComboBoxUIFirstTry.installUI (which goes through the same sequence of steps, eventually calling the BasicComboBoxUI.createArrowButton). And so, the arrow button installed by the main LAF is effectively uninstalled by our extension without it explicitly doing so. Note that this would happen under any other LAF; it’s not Substance-specific.
With this very technical detail exposed, our second try in ValidationComboBoxUISecondTry is to override the createArrowButton() and return null. Not only this adds an unnecessary implementation complexity to our class (which has absolutely nothing to do with validation overlays, by the way), it also results in a nice NullPointerException when BasicComboBoxUI.installComponents() tries to add the null result to the combobox. Obviously, the core Swing implementation of multiplex LAF was never tested under such a simple scenario as adding custom painting to comboboxes.
Our last try is in ValidationComboBoxUI which has to use very “brittle” techniques to preserve the original button appearance. It overrides the createArrowButton(), iterates over all UI delegates picking the one that doesn’t come from our auxiliary LAF, finds its createArrowButton() using reflection (since this method is protected), marks it as accessible and calls it using reflection. Obviously, this is not the best thing to do – the reflection might fail under a stricter security manager and the code is ugly and difficult to refactor.
Here is how our application looks now:
Although the combo buttons look consistent with the application, note how they are four pixels wider than they without our auxiliary validation LAF (18*15 instead of 14*15). What does this mean – yet more exploration of the combobox UI implementation to find which method is responsible for computing the button bounds and, perhaps, yet more unnecessary and unjustified overriding of methods that are not related to our functionality (with possible use of reflection).
So, as you can see, the multiplex LAF is one of the worst techniques that you can choose for the validation overlays and pretty much for any other paint-related functionality. It’s a real pity that after seven years this functionality remains in such unfinished state.
