1. We're here with Romain Guy. Can you tell us more about what you're doing?
I finally left Sun where I was doing an internship with the Swing team and now I'm just a student so I have quite a lot of time to continue working on Swing applications and mostly reach user-interfaces with a lot of special effects.
2. You have a specialty with Swing. Tell us why does Swing still matter?
Swing is still the number one cross platform GUI toolkit. There are others like QT, which is gaining a bit momentum but as of today if you really want to create a UI that's going to work from Windows 95 up to Windows Vista and work on Linux and Mac OS X, you have to go with Swing. And then it's a matter of taste, because I used many toolkits like Qt, MFC, Win32, WX Windows and Swing is the one that I find the best design and the one I'm the most comfortable with. I think that a lot of developers will also think that Swing is a really good tool kit to work with.
3. What makes Swing good for rich clients?
The good thing with Swing is that it looks bad by default so you're going to have to change it to have a good-looking application; Swing makes that really easy because you can overwrite everything, you can overwrite the behavior, change the look and you have this powerful Java 2D API which gives you all the tools that you need to create very rich user interfaces with animations and nice modern effects. It's the same technology that we see in the old Swing applications with the grey colors. With the same technology that they used for that, we can create things similar to Vista. It's really versatile and you can do everything you want.
4. What role should Swing have in this new world of Ajax?
Swing doesn't need to compete with Ajax. They can complement each other. Since I'm using a lot the flicker website. There was a lot of Ajax and for many operations it makes sense. When I do open my photos in flicker I use rich clients because it's just easier. So I think that's both Ajax and rich clients should find the tasks they are best at because it's for the user in the end. Not everything should be Ajax, not everything should be rich clients. There's place for both. I think this is the most difficult thing to do today: forget about all the hype and just focus on what the user wants and needs.
5. So you coined the term "filthy rich clients". What's so filthy about rich clients?
The idea was this: we looked at the rich clients. When you bring up Windows or even Linux, most rich clients aren't that rich actually. They're just grey, dull and they have a lot of buttons and text fields; so we needed to find a term to talk about those rich clients that go beyond that, that is the rich clients with animations, the kind of stuff you see in Vista today or even in OS X We used the term "filthy rich clients" to talk about those clients that try to go beyond the existing user interfaces and ooze cool.
6. From a technical perspective where do you delimit between "filthy rich clients" and rich clients?
I would say that if you start customizing the components, if you start modern effects, especially animations, you're on the right path to the "filthy rich clients". It's a bit like Web 2.0 we know it exists, but it's difficult to know what it is like. It's still a pretty new concept.
7. What do you think the future has in store for Swing and for rich clients?
The future looks bright actually. When you see the latest versions of OS X or even Windows Vista, those big companies are highly supportive of the rich clients and I'm sure that most people are still more comfortable with the rich client application for some tasks. I don't know about you, but I wouldn't use Microsoft Office on the way because it would be awkward. There's room for rich clients and they are getting better and better; they're finally integrating. They steal idea from the web but we have now this integration several medias so you have 3d, you have videos, it goes beyond the images we had so far, so it looks bright to me.
8. When should enterprises consider rich clients within the architecture?
That's a tough question. Once again it really depends on what is the task at hand and what the user should be able to do. There are some cases where you just cannot use a website because the user be using a laptop, or there won't be an available connection or maybe you can rely on the network or whatever. But it can also be simply a matter of some task that are easier to perform with the rich client toolkits than you could do on the web. But there would be harder to implement or more awkward for the user. It's really about the user in the end. It depends on your project.
I think that most people when they talk about that they got the wrong impression. They all want to reduce that size of the JRE which is 7 or 8 megabytes to download. It's not that much. You should download the new version of MSN Messanger, it's a bit more than that. You should download Firefox, it's like 15 M, it's not that much. What they really want is a VM that starts up faster and I totally agree with that. When I launch an applet I'm always pissed that I have to wait 30 seconds for the VM to kick in and this is something that Sun focus on. I think that download size doesn't matter that much.
10. So we don't need a browser edition?
We need a browser edition if we can help to enhance the startup time. If the startup time is the same, but you also have to download other modules because the VM was smaller and it didn't have all the APIs, I think it's not ideal because you'll have to wait even more to download those missing APIs.
11. How about Flash versus Applets? Can Applets ever come back?
I think that Applets don't have to come back because they never really in. There are some good examples of Applets, stuff that you can't really do with Flash and Ajax. There's Think Free Office, online version, it's a wonderful applet. This is the kind of stuff I would use if my laptop is not working. I know that Think Free Office online and even a full screen; also for games with Applets you can do 3D games so that you can have Quake 2 in your web page. There are some few cases where Applets are much better but unfortunately I don't think there are that many cases where you should use Applets instead of Flash.