Meeting Scott Violet

Scott: It’s amazing how fast time flies. Nearly ten years ago I took a job at Sun working on Sun’s implementation of OpenStep. This was right around the time Java adoption started taking off like a rocket ship. As such, Sun’s commitment to OpenStep was waning in favor of Java. When the Swing project began, we felt it important to involve people from different areas, including different companies. Through shear luck I ended up on the Swing team shortly after the project was launched.

I honestly can’t believe I’ve been working on Swing for more than nine years. After all those years I still find it exciting to work on a toolkit. Toolkits never stand still, so there is always the need to evolve them. This makes it challenging due to the changing requirements and needs of developers.

Mikael: What is your role at Sun, and what do you normally do in a workday?

Scott: My current role is Swing architect. I don’t know that I have such a thing as a normal workday. My day varies tremendously depending upon where we are in the release. It can be any of the following: designing new features, bug fixing, customer visits, implementing features, community outreach, code reviews, research. No matter where we are though, I get a nearly unmanageable amount of email.

Mikael: How big is the Swing-team at Sun?

Scott: Engineering-wise we’re at 17. Yes, working on a toolkit that supports five look and feels is no trivial task.

Mikael: Do you use any particular project methodology (such as RUP, XP, Scrum) in your projects at Sun and/or in the Swing team?

Scott: Surprisingly the Swing team has worked extremely well without a project methodology. Project methodologies never proved to useful for us.

Mikael: How do you view the competition from .Net in the rich-client field? Which technology is, to your knowledge, more wide-spread and why do you think that is?

Scott: No less than Evans Data (Spring 2005) reported ‘Swing is the dominant GUI platform.’ How is that for widespread usage of Swing!

Both Microsoft and Apple realize the importance of their respective toolkits and continue to invest in them. As such, we’ll continue to see increased competition from the platform toolkits. This is why the Swing team is staffed like it is. Swing can not stand still, it must continue to evolve.

Companies of nearly any size do not have a homogenous network. Java’s core strength of running on multiple platforms plays right into this. Apps written in Java run perfectly on all the major desktops. This is huge!

In addition, we know of a number of customers that only use Windows, yet favor usage of Java. They cite tools, richness of the language and platform, and no lock in as reasons for going with Java.

Mikael: What do you say to people who come up to you and say that there are no “real” Swing applications (assuming anyone dares say that to you)?

Scott: This is a myth. Swing, and the Java platform, are used extensively for both consumer and internal applications. The number five download on cnet is LimeWire, a Java application! LimeWire has been downloaded more than 70 million times! Maple, a mathematical problem solver, is used in 95% of all universities: 3 million users. Other consumer Java apps include Quantrix, Grokker and Yahoo Site Builder.

Mikael: What do you think about the evolution of the AJAX-technology? Is this going to replace the majority of Swing-based clients as some people are claiming?

Scott: I continue to be amazed by the progress of AJAX. AJAX raises the bar for web apps. Gone are the boring, static HTML pages of yore, they’ve been replaced with interactive AJAX apps.

Very few, if any, of the AJAX apps I’ve seen to date replace Java apps. AJAX certainly gives a richer web experience, but it’s typically replacing what was once a static web page.

Will we ignore AJAX? No! Applets are a great technology for deploying to the browser. We will continue to look for ways to make this more relevant in the face of AJAX.

Mikael: What kind of feedback are you getting from users of the Netbeans GUI-builder (Matisse)?

Scott: A resounding “thank you”. Or perhaps, “it’s about time”!

Seriously though, Matisse lowers the bar for how developers approach the process of creating a Swing UI. No longer do developers need to worry about the underlying layout manager. Developers need only move around components as in a drawing program. It’s that simple!

Mikael: JSR-295 (data binding) and JSR-296 (Swing Application Framework) attracted a lot of attention in the audience at JavaOne this year. What kind of reactions have you gotten from the community for these new projects?

Scott: The community is excited for a number of reasons.

Sun’s commitment to rich clients has always been questioned. That we are doing JSRs publicly shows Sun is committed to Swing and rich clients. That’s huge!

Both JSRs address very common pain points for Swing developers. When combined, 295 and 296 will greatly simplify writing Swing applications. That’s a long term goal you’ll continue to see from us, making your job easier!

That we are doing JSRs for client features allows more community involvement that we historically have had. This is great for both parties. By engaging the community we ensure the end result really addresses the need.

Mikael: Data validation is one of the things every Swing developer has to struggle with. Is there any work being done in this field at Sun?

Scott: Beans binding (295) will provide the necessary hooks for validation.
It’s too early in the design phase to say how it will work out, but suffice is to say it’s a problem we care about.

A new JSR has just been filed for validation. To ensure alignment with beans binding, I am on the expert group as well.

Mikael: What is the next big thing for the Swing-team?

Scott: Beans binding and app framework aren’t enough? For two years running Shannon Hickey, Romain Guy and myself have done talks at JavaOne titled ‘Extreme GUI Makeover.’ Both years attendance and interest has been huge. We would like to make it easy for developers to create rich, compelling user interfaces. You’ll see a number of initiatives from us in the coming years on this.

Mikael: Is there anything else you would like to add before the end of this interview?

Scott: A big thanks for the interview!