Java on the Desktop, the past, the present and the future – interview with Richard Bair

December 5th, 2008 | 13 Comments »

In this interview Richard Bair answers my questions on Swing, SwingX, JavaFX and Java on the desktop in general, saving some of the announcements for the next week’s Devoxx conference. We wanted to do this interview immediately after my thoughts on the state of core Swing, but the JavaFX release has postponed it up until now.

Tell us a little bit about yourself.

Like many developers I know, I started programming because I wanted to write games. Somewhere along the line my dad convinced me to write him a database backed application for his business, and that’s how I got started.

Since then I’ve been predominantly an application developer. It was in that role that I started working with open source software, and eventually started working with JDNC. I was subsequently hired by Sun and have been the SwingLabs lead since that time.

It hasn’t been all smooth, I learned a lot about open source community building as I went along, and certainly have plenty of faults in getting SwingX releases out regularly. But my overall goal and desire has always been to make building real world applications easier.

I know in the recent past I’ve been involved a lot in Java demos and such that are consumer in nature. I like building applications, either consumer or enterprise. Consumer applications are closer to what got me started in programming in the first place, while enterprise apps are really where I cut my teeth (one of a handful of engineers I’m sure who love both big iron databases and pushing pixels ;-)).

Why was SwingLabs created, how did it evolve and what is its current state?

SwingLabs was a bold attempt by the Java Client Group to engage the open source community long before OpenJDK came along. Originally the brainchild of Amy Fowler and Hans Muller (and probably others on the team), the idea was to have an open source venue for building APIs that fill in the missing pieces of what is shipped with Swing.

As any Swing developer can attest, you have to build a lot of plumbing to build real apps with Swing today as shipped with the JDK. In the last few years a great many open source projects have been created to help fill these gaps.

SwingLabs was also designed as a place where these APIs and experiments could be vetted and included in the JDK. Our score in this regard is not so good. We pulled in a lot from the JDIC project, and we pulled some of the filtering and sorting work in.

We will be pulling more for JDK 7 as well, expect to see 2 or 3 components at least and also one or two big JSRs.

SwingLabs is currently run predominantly by the community which is really working I think pretty well. The dedication of our team of open source developers is a credit to them and to the open source reality that we live in.

We do need more involvement from the Sun side, and will be making an announcement in this direction at Devoxx next week.

If you were to start over with SwingLabs / SwingX, what would be the most important parts in building and maintaining the community involvement?

Regular releases. Regular content added to the SwingLabs.org website. More responsive bug fixes (my fault entirely).

Would you like to provide your side of the story behind the decision on the layers and painters in SwingX?

The fundamental idea behind painters was to decouple the rendering of components from the components themselves, such that you wouldn’t have to subclass the component to change its rendering (or replace its LAF which is a much more complicated proposition). The corollary was that there could be a collection of default painters that people could reuse.

There was an argument made primarily by Mikael Grev who had a similar API in his MIG Calender component (if I remember correctly) that we should have components that support painters to have an arbitrary sequence of painters. Sort of like JLayeredPane but for painters. I know Scott, Romain, Josh, and I didn’t particularly like it for technical reasons (which are all documented in the forums), and there was both support and skepticism from other people outside Sun.

At the end of the day, the project lead has to make a call on API, and I made the call I felt most comfortable with.

How likely is it to see the SwingX components being part of core Swing in JDK 7 and beyond?

All of them? Unlikely. Some of them? Extremely likely.

Originally Nimbus was planned to be developed under the SwingLabs roof, but was later put into the internal repository. Would you like to see the development of new Swing-specific functionality in the open before it gets put into the core distribution?

Nimbus is a special case. To properly implement Nimbus required a significant number of fixes and enhancements to BasicLookAndFeel, Synth (lots of bug fixes for Synth) and other core APIs and implementations. We simply could not have delivered Nimbus in the open source without these fixes. Also, Nimbus went into Java 6 Update 10 which was not part of OpenJDK. When Nimbus is forward ported to Java 7, it will be in OpenJDK.

I would prefer that all development was done as part of a community process, be it SwingLabs or an open JSR or OpenJDK.

Do you think that maintaining backwards compatibility has unnecessarily restricted the Swing team in moving this UI toolkit forward?

No I don’t. If you gave up backwards compatibility you’d have a whole other set of issues that are many times worse. The level of risk one developer is willing to take isn’t the same as another. For every one person who wishes we’d ditch backwards compatibility there are another 50 that would be violently opposed when that advice rendered their applications (or development of future versions of their applications) inoperable. Especially with a technology as mature as Swing.

To those people who say we should make a Swing2 which is not backwards compatible, I would say, this is exactly what we’re doing with JavaFX.

I also want to emphasize that Swing isn’t going away. We have a tremendous number of customers building Swing apps and that will obviously be supported and extended going forward. Also, we will allow you to mix JavaFX both into Swing apps and mix Swing in JavaFX.

Both Microsoft and Adobe view “line of business” applications as a very important target segment for their offerings (WPF, Silverlight, AIR, Flex). Is JavaFX only targeting the rich UI development (graphics, effects, animations), or do you plan to include modern business components such as pivot tables, grid trees and date pickers?

JavaFX 1.0 is oriented toward creative content, very similar to Silverlight 1.0. Future versions of JavaFX will be designed to also handle full blown enterprise rich client application development.

What effort is planned to be put into the core Swing in 2009?

We’ll have announcements for these plans at Devoxx.

Anything else you would like to add?

As an application developer, and as a toolkit developer, JavaFX is very exciting for me. The first release is really aimed at providing the foundation for all subsequent work. We’re focusing on animation, graphics, media, and related APIs with an eye towards the future so that we have a solid foundation upon which to add user interface Controls, frameworks etc. JavaFX gives us the freedom to design the best possible design we can, without any API backwards compatibility constraints. It really is an exciting opportunity. We’re committed to providing interop between FX and Swing so that people can build the kinds of applications they want to, and can mix and match the two.

---

Related posts:

1. Java desktop spotlight – interview with Sam Berlin of LimeWire I’ve talked about LimeWire in the latest installment of Swing Links of the Week, and...
2. Java desktop spotlight – interview with Elie El Khoury of Woopra Woopra desktop client is my favorite Swing application of the year, and it’s time to...
3. Is one of my Java desktop 2008 wishes coming true? I had only two things on my Java desktop wishlist for 2008 – cross-platform support...
4. Java on the desktop I’ve said before that the customers don’t care about the technology. To a certain extent,...

---