The Reponse to Why Don't you Ship Swing Apps
It's been a while since I posted my original weblog on why some developers aren't shipping Swing apps, and it's gotten over a hundred responses! This makes me happy because it means there are a lot of you out there who really care about desktop Java and want to ship good apps. It's our goal to make Swing the best way to write a quality desktop application, so all of this feedback is great.
Going through all of the responses I've started to see some common complaints. I want to address these themes, dispel a few myths, and let you know about some of the improvements coming in Mustang.
Performance and Memory Usage
J2SE 5.0 made a lot of improvements. Startup time should be faster and memory usage lower. Mustang has even more improvements, especially in the drawing department. We've got improvements for subpixel anti-aliased fonts, fixing the Gray Rect problem, a single threaded OpenGL pipeline for Java2D, and more improvments to Direct Draw 3D. We are working on getting memory usage down in general, and hope to have more class sharing. In short, Mustang will be better.
Deployment: This is probably the number one issue. I expected it to be up there, but not above Performance. I guess that's a reflection of how fast Java is now (and how fast our computers are). It also reflects that fact that you guys are building real applications that you need to ship to real users. This is a good thing. Also good is the future of deployment. Basically, it's better than you think, and it's going to get a lot better.
Java Web Start
First, right now you can use Java Web Start to make applications that are almost as easy to install as an applet. If you have limited need for local resources (like disk access) then you can deploy your application without being signed. This makes the application run in a secure sandbox like an applet but run outside of the browser (with a desktop icon!). WebStart is still undergoing improvements, but you can do quite a lot with it right out of the box. If you are serious about shipping Swing apps and haven't looked at Java Web Start then you need to go check it out right away. Oh, and that scary looking "don't run this app" dialog is going to get a lot better, as Stanley Ho's recent weblog shows.
Java Auto-Install Toolkit
Going forward, our Human Factors group has made deployment one of the top priorities. We have plans for a unified download infrastructure that will improve download speed and centralize the code base. There will be a new version of the Windows download component that will improve detection, platform, and browser support. All of this will make it easier to get your user's running Java, and the right version.
Smaller JRE Download
Third, download time has been a big complaint. Lots of developers complain, and rightly so, that their users don't want to download a 25 meg runtime just to run a 5 meg program. The answer is that your user's don't have to download 25 megs to run Java. The Windows version of Java can be installed with a 216k installer program that will download the bare minimum. That minimum comes in at 7.2 megs, including everything you need to run Swing apps. Any missing features (other languages and such) can be installed from the Add/Remove Programs control panel. Stanley Ho's recent blog post explains more.
I never knew the base JRE was so small, and I've been developing Java for 10 years! I think this misunderstanding stems from the fact that we are all developers and so we always download the JDK, which is in the 25meg range these days. Our users, though, get a much smaller download. Suddenly deploying to users without Java doesn't seem nearly as daunting.
Visual Appearance (ie, don't be ugly)
A lot of people have complained that Swing is ugly. When they say this, they usually mean that Metal is ugly. Metal was actually considered pretty nice when it was first built, but that was the mid 90s when most of the world still used Win95 and System 7. Metal has gotten much better (ex: the new Ocean theme is a huge improvement) but it's not going to look significantly different going forward because of one simple reason: backward compatibility. We can't change anything in Metal that would result in different sizes or layouts. Too many old applications are hardcoded assuming certain sizes for the components. Most changes would break that. You can customize Metal yourself (with different fonts and colors, for example) but the default pretty much is what it is. There are a lot of other great options, however.
Synth and Other Look and Feels
The answer, of course, is you don't have to use Metal! Use the native look and feel. Use a third party look and feel like JGoodies or one of the many themes on www.javootoo.com. Use another layout manager like JGoodies Forms or TableLayout. And Mustang is planned to have baseline support for even better layouts. It's really up to you what you use. This is your application. When I see an ugly webpage I don't blame my browser, I blame the site designer. We should all spend a little time making our applications look good. Tune the colors and fonts. Tweak the interfaces to make them easer to understand. Show it off to our friends. The tools are out there. Always use what is appropriate for your application. And if you can't find the tools or they have bugs, please let us know!
It would be nice, of course, if Sun provided some better tools. The good news is that we are. Synth is an XML based L&F that works entirely with images. The documentation is currently sparse, but it's getting better, and we are having someone build great looking example themes this summer.
Windows Look and Feel bugs
Speaking of the Windows Look and Feel, one of our biggest complaints is the lack of native fidelity on Windows. We've got a whole lot of fixes coming for this, including some that I'm personally working on. We're also working with the open source winlaf.dev.java.net team to catalog the known bugs and build unit tests. It's our goal to make 1.6 the best release ever for Windows native fidelity. (plug: please download Mustang and try it out). When 1.6 comes out we hope you won't know the difference between Swing and native apps.
Swing is hard and has no examples
Swing can be hard because it does everything. It's powerful, but you need to understand how to use it. This is a good thing, but we want to make it more accessible. I'd rather have former JSP coders looking for their rich client solution come over to the Swing side instead of looking at .NET or Flash. We are tackling this in three ways:
There is a new JSR in the works to add categories to javadocs. This will let us separate the useful features like event handlers from the implementation details like the update() method. The result will be clearer and easier to read documentation. Once the tools are in place it will take a while to update all of the javadocs, but we're working on it.
Swing is a toolkit, not a framework. It gives you the tools you need to do anything, but no sense of how to put them together. J2EE went through this with the transition from straight Servlet and JSP code to frameworks like Struts and Spring. Client side Java must do the same thing. In the last year we have seen the emergence of rich client frameworks from the likes of Spring, Eclipse, Netbeans, and JDNC. We think these frameworks will solve a lot of the 'building a large application' issues. Several members of the Swing team are contributing to the SwingLabs project to help get applications up and running as quickly as possible.
Swing doesn't have the equivalent of the J2EE Petstore application. There should be at least one (preferably 3 or 4) non-trivial example applications built entirely using Swing. The purpose of these applications is to show developers the correct way to build a large application. How do you structure your code? Where do you put event logic? How do you properly localize it? The good news is that we are planning several well documented example applications that you can not only use as examples, but use as a base for your own applications.
New Components and Frameworks
We are busily adding new components to Swing and AWT. Some of the JDIC features like the System Tray and Web Browser APIs are making their way into the core. In the future we plan to integrate other components from JDIC and SwingLabs, but before you go listing your favorite addition I'd like you to think for a second and ask yourself Do I really want component X pulled into Swing?
What does putting a component into Swing proper really get you? Well, it will be supported by Swing experts who will debug it and keep it up to date. You also don't have to worry about including an extra jar. This is good, but what do you lose? A component in Swing is tied to Swing's release schedule, which is tied to J2SE in general. Do you really want to wait 18 months for new features in this component? Keeping advanced components as open source projects is really a better idea. Then you can fix bugs directly, add features you care about, and not worry about the general Java release schedule. Sure, you have another jar to download, but isn't the extra few hundred kilobytes worth it to make it do what you really want?
Components should really only be put into the Swing core when they are stable and not likely to change significantly. For everything else there are great opensource projects on Java.net, often with the same Swing engineers working on them. If there's something you feel is missing from Swing, I recommend going to SwingLabs first and asking. I think you will be pleasantly surprised.
Well, I think that's about it. We've got lots of great stuff coming, and you can check it all out by downloading the latest build of Mustang. All of the cool new stuff will be previewed there first and we really want your feedback.
Thanks, - Josh
Posted May 9th, 2005