Joshua Marinacci's Blog

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

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

Second, you need to make sure your users have Java in order to run your application. There is a Sun provided auto-install component that, with some html and javascript, will detect if a user has Java and Java Web Start installed and push it to the user if not. Right now this system is under-documented, requires some javascript hacking, and only supports Internet Explorer on Windows, but it works. More details are coming soon.

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:

Better Javadocs

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.

Frameworks

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.

Examples

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.

Conclusion

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

Comments

• Also nice to know; what are YOU doing with all that feedback. I'd like to note that (for example) saying javaws is pretty good as is makes you look like you failed to grok those posts since the immense number of small bugs make it hell to maintain in a non-corporate setting.
  Cheers!

  Posted by: zander on May 09, 2005 at 01:04 PM

• A response to the response:
  A lot of developers (if not more than any other client side lang) are eager to ship Swing imo. W/ JDNC, I think Java will finally completely dominate.
  Java Web Start
  Stanely Ho has also gotten a lot of responses to his idea. Over 80% were deleted somehow! I am not saying who/why, but they are go. The major part of feedback is that any warning to users is scary. If the apps are self signed, temp or invalid, there should be warning. If they are verified authenticated (see the steps http://www.thawte.com/guides/pdf/enroll_codesign_eng.pdf ) and the jars are signed, there should be no warning screen. You are only preventing deployment.
  For example, if I install LimeWire, it ships w/ JRE and no warning. If I install Flex/Flash, same. So duplicate that, and back port it to 1.5, else it's on interest only after Mustang is widely deployed.
  Try Gosling's https://jnn.dev.java.net w/ 1.5.0.3.
  Let me kick the dead horse again: 80% of posts on Stanley Ho's blog are gone mysteriously, the warning screen is there, he has just done MINOR word smithing, and no word on fix to 1.5.x. I am not sure if he is the man to do this, and we are all in line behind. He has been at it since 2001 and it might take him another 4 years. Someone else should get a chance, like Mike, the UI guy. As per the “online chat” it seems that Stanley Ho's sees his role to prevent deployment as it might not be safe on windoze.
  Where can I find the auto install kit for FireFox? The one for IE is good. Url?
  Smaller JRE download
  Again, take Limewire, the include the JRE, because (of web start problem) 1.5 best practice is to include the JRE w/ your app distribution. (Ex: How many jres do you have? http://www.javalobby.org/java/forums/t18329.html ) The jars are not compressed. Do we relay need corba on J2SE? (why not mark as deprecated in 6.0 and move to J2EE).
  Why do I have to include jGoodies layout? (gridbag is not maintainable)
  Let me kick the dead horse again: best practice is to include JRE w/ your app. untill WebStart is fixed (in 1.5.x).
  Visual
  Metal is ugly. We don't need cross platform, that myth is widely debunked. It has to look nice. So I ship w/ jGoodies.
  Windows L&F is not for applications that try to look like web applications. Look good is good. (http://www.jroller.com/page/gfx/20050504 – scoll to INCERBILE LOOKING SWING APP)
  Swing is hard
  Most examples are not MVC. If you show example, show how you can unit test M and that it's modular. I'll help!
  Swing does not have Petstore.
  THANK YOU, THANK YOU. Good job! (Scare yourself, look at JDNC adventure store sorce code)
  “We have found the enemy, and it is us.”
  .V

  Posted by: netsql on May 09, 2005 at 02:44 PM

• About the backward compatibility thing with Metal, I do appreciate how much attention Sun gives to backward compatibility, but sometimes it is overdone, and Metal is a case in point. Look at OSes like Windows and Mac, every few years they have change visually, and very surely the transition has been painful for a large number of application developers. But that has not kept these platforms from changing with the times. By stubbornly refusing to inflict pain on the minority who actually depend on GUI hardcodings to work, Sun disappoints the much larger majority which is put off by the no-longer-modern Metal.

  I can't empathize fully with the web design analogy either. Good GUIs need careful attention, but Metal being the default means a bad experience out-of-the-box. I use Firefox to look at web pages all right, but a small part of the reason I don't use IE to look at them is Firefox plain looks and behaves better.

  Posted by: sumitkishore on May 09, 2005 at 02:51 PM

• Uhh, regarding the toolkit vs framework discussion, what is the Swing team doing framework wise? JDNC doesn't go far enough to be called a framework for rich client apps. Are any other ideas underfoot? The Netbeans RCP being adopted for a generic framework?
  

  Posted by: sumitkishore on May 09, 2005 at 04:27 PM

• To answer you, sumitkishore, I don't work at Sun, but I know one person there who's making sure that netbeans platform 4.2 will be a _lot_ easier to develop apps on top of, and I know there a UI engineer working on a team creating good netbeans platform/JDNC integration.

  Posted by: richunger on May 09, 2005 at 06:24 PM

• There is an anomaly with Stanley's blog such that it has two URLs, which is why it may appear comments have been deleted. They haven't.
  The original URL only contains 10 comments:
  http://weblogs.java.net/blog/stanleyh/archive/2005/04/deployment_good.html
  Whereas this URL contains 58 comments:
  http://weblogs.java.net/blog/stanleyh/archive/2005/04/deployment_good_1.html
  Josh, it may be good if you could update your blog to point to the second URL.

  Thanks for the update on this stuff.
  I'm very curious to know what you're hinting at when you say about deployment: "it's better than you think".
  Any more clues?

  Graham.

  Posted by: grlea on May 09, 2005 at 07:42 PM

• sumitkishore:

  I totally agree there on the Metal look & feel compatibility.
  Though I must say that I always use a 3rd party L&F (JGoodies), I think it would be good for the platform if the default wasn't butt ugly.
  I think the default should be the system look and feel, as this seems to be what the majority of people want to see at the moment, and those of us who like something a little different can keep doing it how we have been.
  People who desparately need to have their application running with Metal can do one of two very simple things:

  Don't run it on J6 (duh)
  UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");

  
  Graham.

  Posted by: grlea on May 09, 2005 at 07:55 PM

• Thanks for keeping us up to speed about what's going on. Here are some additional thoughts and considerations. Swing: It's absolutely necessary to make Swing accessable to a programmer community that is thread-agnostic. i.e. all those former VB guys. That, of course, is only necessary, if the Java world is interested in business driven applications on the desktop. Ben Galbraith is working on these problems as you are probably aware. Java WebStart: I just learned yesterday how little control I have over the classpath compared to an installed program. Considering the importance that the classpath has in a Java application, I am still quite shocked about this. In short: Make Java WebStart work as closely as possible like an installed application. L&F: I agree with sumitkishore. Kick Metal. This beast has done so much harm, that it's probably impossible to express in numbers. I really don't want to know how many people in higher ranking positions have buried a Java project after the first presentation/prototype because of Metal. So get rid of it.

  Posted by: norb on May 09, 2005 at 11:38 PM

• Regarding the "Swing is hard and has no examples" point--

  I teach Java at the University of Pennsylvania, and I teach a little AWT. After that I require Swing, but don't bother teaching it. This is painless for the students (at least, no one has complained, and they complain about a lot of other things) because I provide them with (ahem) a very nice little program I have written:
  www.cis.upenn.edu/~matuszek/General/SwingExamples.zip

  This program is unusual because it reads and displays its own source code; for example, when you click on a button, it displays the code for creating that button and for capturing the event. (It's also unusual in that comments are significant.)
  Anyone mistrustful of this program is welcome to examine the source code, which is included for obvious reasons, and recompile it. One of these days I'll get around to figuring out how to read the source code if it's included in the jar file.
  I'm posting because this program has worked so well for me, and I really think this is the sort of thing that should be provided as a way for developers to get started with Swing. Of course, only a small subset of Swing is represented by my program--just the most needed things. If anyone is interested in expanding this program, please consider it open source; and if you add to it (without greatly increasing the complexity of use), please let me have a copy.

  Posted by: matuszek on May 10, 2005 at 07:14 AM

• I'll be interested to hear more about the new deployment strategies. Needing to have local admin privileges to install the jre is a frequent problem we have with rollouts. This is why I'm so keen on hearing about the active directory/elevated privileges msi installs, which will help with at least the Windows based roll outs. The ActiveX/Javascript route is frequently a none starter as cooperations are becoming wiser about security issues, speaking of which..

  I guess there's not much that can be done for clients with secure, tied-down desktops or worse still the shared company (disk) image coupled with an irrational fear or Java.

  Don't suppose the new era of glasnost with Microsoft would strech so far as having Mustang preinstalled with every copy of Lornhorn ;)

  Posted by: osbald on May 10, 2005 at 07:31 AM

• I'm not sure why it doesn't get more press, but the fonts in Swing stink. They have never looked good, and still, in 1.5, do not look good. I create an app with SWT on Windows and get nice anti-aliased fonts for menus, text boxes, etc. In Swing, I get pixelated, aliased fonts. The fact that it is 2005 now, and this still hasn't been addressed is a sad statement.

  Just ask yourself what percentage of desktop apps out there use text in one form or another, and you will know the percentage that will look amateurish in Swing.

  Posted by: sstrenn on May 10, 2005 at 08:54 AM

• Fonts are another one of Metal's areas where insistence on backward compatibility is hurting Swing. Metal still has those big bold chunky fonts by default that scream "amateur", and I've seen Sun's response in the past being "some clients depend on these font sizes and types". Sun does all the hard work technically - Swing can pick up system fonts and font sizes, it can anti-alias fonts, and so on, *IF* you use the correct command-line option, because by default it's backward-compatible. Boom - most people never see the change.

  It was a similar story with J2SE 1.4 and assertions - they were provided but were off by default. In my team makefiles are maintained by one guy. If assertions were disruptive (they were not), he would have changed javac options to be backward compatible and none else would have noticed. As it is, J2SE 1.4 was backward compatible, we smoothly transitioned to it without a change, and even today developers are not getting indoctrinated into using assertions because it is off by default.
  

  Posted by: sumitkishore on May 10, 2005 at 10:10 AM

• We need a library for creating our own auto-download programs, too, just like JRE downloads itself, in addition to WebStart. I know of a number of projects that investigated WebStart and decided not to go that route, but then they each implemented their own auto-update/plugin-finder systems. A common one would be a big help, or at least a good tutorial.

  Posted by: gerryg on May 10, 2005 at 03:22 PM

• Josh, thanks for taking the time to post the feedback. It is a huge step forward just having someone senior at Sun listening/responding to these issues.

  +1 in re: deprecating Metal.

  And, at the risk of being verbally lynched, I'd like to ask you to look to the future of rich clients, even while working to fix the current state of Swing. I've seen Microsoft's demos of XAML and it is scary-cool. So let's not get so focused on 1990s style GUIs that the Mustang version of Swing looks outdated as soon as it is released. Think about hauling in the LookingGlass people and trying to beat Microsoft to the punch. "Embrace and extend" can work for Java just as well as it has for Redmond.

  Posted by: rodmac on May 10, 2005 at 06:03 PM

• First you mention that Deployment and Java Webstart are "priority number one" and then you go on to mention that "things will improve in Mustang" but don't give any hard facts.

  From what I've seen so far I am quite disappointed with how much new Java Webstart stuff is going into Mustang. If it's such a high priority Sun should be doing *more* in that department and less in the others. Right now it seems they are making a lot of noise about it being important but not publishing a list of major Webstart issues they plan on improving.

  Does Sun lack ideas in this department? I'm sure developers are full of ideas to contribute...

  Gili

  Posted by: cowwoc on May 10, 2005 at 10:12 PM

• When 1.6 comes out we hope you won't know the difference between Swing and native apps.
  Given the current state of JFileChooser with XP L&F that will be quite a feat!

  Well I am very happy now that I know that desktop Java is getting some much needed attention.
  Thanks Josh!

  Posted by: jdolphin on May 11, 2005 at 01:51 AM

• Thanks Josh for taking these things seriously. Regarding the pros and cons of rolling components into Swing, one nice thing would be having the component(s) receive equal treatment for all target platforms. In the case of the web browser APIs, this means (I hope) that they would run equally well on all platforms that support swing.

  Posted by: powerdroid on May 11, 2005 at 05:46 AM

• Back now! Let me respond to these one at a time:

  zander: I do think that JWS is pretty good. There are some things it doesn't do very well yet, especially when it comes to security issues (signing, the scary screen, un-signed network access), but these are all being addressed and fixed. It's still pretty good though. I can write a desktop app on my computer that my mother can use on her mac at home and her PC at school. I know I can just send her a weblink and she can run it. That's pretty cool. When I push an update she'll get it the next time she uses the app. And I can do all of this with off the shelf technology. That's really cool. I can't do that with a native windows or mac app, or at least not without jumping through a lot of hoops. Sure, it has bugs. All new technology does. Remember the days of writing cool websites when you had to work around Netscape and IE bugs on 3 different operating systems? It wasn't the best in the world but it worked. And things got better. A lot better. I think the same is true of JWS. You can do a lot of cool stuff now and it's going to get better.

  netsql: JWS: security is a big deal and we take it seriously. A signed app is just that, signed. That doesn't make it safe. But then downloading limewire isn't inherently safe either. It's only because you trust limewire.com that you run it. We are trying to strike a balance between writing power apps and safe apps. Part of this is the security screen. I think the new one is great and does a better job of conveying to the user what's going on. It basically says: This app wants to run. Click yes if you asked and trust this website to run the app.. We don't live in the world of '95 anymore. Applications have to be more secure. Both XP and OSX exhibit the same behavior where they post a warning about potentially unsafe content, apps that ask for keychain access, etc. This is a good thing. JWS apps work along the same lines. Plus, with the new socket controls the need for unrestricted access will be greatly lessened.

  I don't know when the Firefox kit will be available or where the IE version is. I only know it's being worked on. I will find out more information and post it for you.

  I'm not sure what you want on the JRE. If the user already has 1.5 you don't need to install it again. The jars of the JRE are compressed (very tightly) and with 1.5 you can compress your own jars with Pack2000. Standard zip compression has always been supported.

  sumitkishore We are working on some thing to manage defaults and deal with backward compatibility in a cleaner manner, however that doesn't stop you from running with a Look and Feel other than Metal. You can switch with a single line of code. It's your app. Make it look good. That makes your app stand apart from other apps where the developer simply didn't care. Perhaps if we had a nice gallery of available LaFs it would help.

  Posted by: joshy on May 11, 2005 at 06:14 AM

• norb: I don't think VB is thread-agnostic. I thought it just restricted you so you do everything on one thread unless you specifically request otherwise. Swing is a toolkit, not a framework, so I wouldn't want to restrict what Swing gives you with issues that belong in the framework. That said, we are doing things in JDNC to make it a lot easier to deal with threading issues. I also think that SwingWorker is going into 1.6, which should help out too. I can't comment on other projects under development, but I can say that we are doing things to make Desktop Java attractive to VB developers and former serverside ASP/JSP developers.

  matuszek. This looks pretty cool. I'll take a look at it. Thanks!

  osbald: I'll try to get more info for you on the IE install kit and what's coming. I know that we are taking Longhorn seriously. We should look great on it the day it's released.

  sstrenn: I believe you can turn on anti-aliased fonts globally in 1.5 with a system property and there are workarounds for 1.4. Fonts are a big priority for Mustang.

  gerryg: JWS does the auto-updates by default. Are you saying you'd like this functionality in non-JWS apps too? I'll take a look at what's available. I know there are some 3rd party tools that can do it.

  rodmac: Thanks for your compliments. In answer to your question, we are taking Longhorn quite seriously. I'm personally interested in what XAML is doing and how we can do it better (and sooner). There's actually a lot of cool flashy stuff you can do right now. Take a look at some of the things that Romain Guy is doing. book plug: and Swing Hacks that Chris and I wrote will show lots of really cool features and effects. And almost all of them work under 1.4

  cowwoc: Facts for Mustang are being divulged as they become available. Considering we are talking about pre-release software that won't be RC for a year and think we are being pretty proactive. You can always download Mustang to try out the new features and watch the bug list. I'm telling you everything that I know. We want to get information and new builds out to you guys as soon as possible. Compared to Apple and Microsoft I think we are doing pretty well. You don't have to pay for a full ADC or MSDN subscription to download Mustang. It's free! Not to mention the fact that Apple doesn't have it's developers posting information about new features in weblogs. I think we're pretty open in this regard. Is there more you would like us to be doing?

  Thanks for all of your feedback. Keep it coming!

  Posted by: joshy on May 11, 2005 at 06:38 AM

• Many of these issues have been solved on the Macintosh for some time. Since, heck, what, OS 8.1 the Mac has shipped with a VM (arguably so has Windows for years, as 1.1.4 can do a little Swinging), and since OS X was released, Java 2 is on every Mac out of the box. There's no JVM download, and the Aqua native look and feel makes it so that your apps don't look any different than native ones, if you've done a good job laying out your widgets -- I should know; I've had people mistake my Mac Java shareware app for native more than a few times.

  Folks, the Mac is a great place to start if you haven't already considered it, mostly for the same reasons id used the Mac first to test Quake 3: platform homogenity. For Java, the runtime's there waiting on you, and you've got a great native look. Don't let limitations deploying on Windows stop you from writing great apps deployed on the perfect test platform -- OS X -- now.

  
  This being true, I have to wonder why there aren't more ringing success on X. Are we really shooting for the right problems [on Linux and others, but mostly Windows] in 1.6 if they've been answered already on Mac and there aren't more successes? What needs to be done to hit the desktop app "tipping point" (joelonsoftware.com reference) for Java on Mac, and how can that best be extended to other platforms?
  

  Posted by: rufwork on May 11, 2005 at 11:11 AM

• Fonts, fonts, fonts!

  That would be one #1 complaint (at least under Windows). Either the fonts are utterly wrong or their rendering is abysmal (remember the infamous '8' character in whatever default font Swing uses?). Handling of fonts should be top priority.

  Posted by: jacek on May 11, 2005 at 01:58 PM

• I really like the direct response to the many comments. It is great to see that Sun spends money on keeping up a lively community and I hope this continues. It is a pleasure to see others care.

  A few comments that came to mind while reading:

  Deployment

  It seems as if there are not so much news to tell about deployment already. Still what is missing for Java desktop applications is the availability of a JRE on every desktop. The JRE is shipped with many Linux distributions and is part of the Apple desktop too. Is it not possible to make the Windows version of the JRE that is downloadable from java.sun.com a part of the Windows distribution too?

  
  Java Web Start

  Java Web Start is great but see 'Deployment' above. It requires a JRE. It is difficult to explain to users: 'Starting this application is as simple to click this web start link.... but hey, you need to download the JRE first, it is only 25 MB and then you simply have to install it, and to install it, you need to....

  See what I mean? Web start is useless without the JRE no matter how good it works.

  
  Java Auto-Install Toolkit

  Is this necessary? I have the feeling that the installer at www.java.com is quite good already. The pity is that the user has to download and istall a big JRE maybe to web start a tiny 30 KB trial version of a most recent cool widget.

  
  Smaller JRE download

  Now that is really great news! You wrote 'I never knew the base JRE was so small, and I've been developing Java for 10 years!'. I did not know either, an the reason is that the JRE was not that small for the last 10 years. Stanley Ho's blog shows only the link to the most recent Java 5 update and this download link will not be there forever. Can we have more explanation on how to build a smart insaller that can be used such as a typical 'setup.exe' on windows and which installs a 7 MB JRE along with a typical 1-2 MB swing app? How about a real and well documented 'JRE minimum installation bundle' with support for online and offline installation? With additional optional packages for special needs also readily bundled?

  ....the above is just for discussion. As mentioned previously, in general I really appreciate all the efforts Sun takes to keep Java alive.

  Posted by: uhilger on May 12, 2005 at 12:39 AM

• Font, fonts, fonts. Subpixel AA is still not in Mustang builds. And please make it fast ("plain" AA is rather slow when enabled). Btw, talking about next wave of rich client applications, look at what Longhorn can do, and it even makes it super easy, with combination of declarative XML programming (packed with various effects out of the box and probably supported by tons of easy drag-drop-point-click builders) and super fast rendering engine. OSX Tiger already has similar bits an pieces, and Gnome-KDE guys are in the middle of producing similar experience for developers and users.

  www.longhornblogs.com, scroll down to Agave screenshots, and compare with great looking Swing app at http://www.xerto.com/images/screen-shot.png
  

  Posted by: selendic1 on May 12, 2005 at 01:21 AM

• To get the ~7MB installer, you just need to use the windows online jre installer.

  If you are interested in extracting the jre msi file out of the offline .exe installer to be used with Active Directory, instructions are at:

  http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/install-msi.html

  We added support for installation with elevated privileges in Mustang (6.0).
  

  Posted by: billyh on May 13, 2005 at 11:42 AM

• Let us look more real:

  1. Startup time. You 've said about startup improvements in java 1.5. Well my Microsoft Word starts a several times more quickly than only pure JRE loads! Moreover, a java application jars must be loaded and linked EVERY time the application starts. WHY NOT make application jar classes precompiled y cached like it makes JRE for it's runtime classes?

  2. Memory. Well it is not so critical when we have only one application started. But if a user will run 2-5 simultaneous applications, the problem will appear. WHY java DO NOT use shared class code in memory?

  3. Integration with system desktop is very poor. On the contrary the Sun's paradigm of system independant application, REAL desktop applications require system features!
  - system tray
  - file dialogs are not implement all features the system file dialogs have
  - integration with system applications like webbrowser, mail client, etc...
  - use of a ActiveX inside Swing
  - etc...

  4. The set of Swing standart widgets may be extended for needs of real desktop application.

  Conclusion:
  I'll beleive in Java and Swing ONLY if Sun (or somebody else) will successfully demonstrate the power of Java with an office-like suit.
  

  Posted by: nullpointer on May 16, 2005 at 03:04 AM

• Hmmm, those instructions go to pains to tell me how to extract the .msi file. i.e. The easy bit. Then just gives a vague now go use Active Directory - not very helpful as I whined about earlier. Also spelling out the transforms needed for installing the plugin would be helpful instead of a link to an MSDN reference page.
  I thought j2se 5.0u3 had a fix to the extracted .msi, elevated privs install? mustang..? ah well, see you this time next year (maybe).

  Posted by: osbald on May 16, 2005 at 03:06 AM

• The 5.0 train does not have support for elevated privileges. This was a new feature added to the 6.0 release.

  A transform (.MST file) is a difference between 2 msi packages. When a transform is applied to the msi file during the install using the TRANSFORMS= property, the difference is also applied. So to register the jre with a browser, a transform needs to be created and applied to set the IEXPLORER and/or MOZILLA properties to 1.

  The MSDN website has the most up-to-date, accurate information on how to use Microsoft's Active Directory technology. The main point of the link was to show how to get our jre msi file.
  

  Posted by: billyh on May 16, 2005 at 08:20 PM

• Sorry to be picky, its just that I feel its so important to get the runtime onto the clients machine with the least fuss. I'm so frustrated that these instructions aren't being shouted from the rooftops! rather than a couple of paragraphs hidden away which practically say "go work it out for yourself". What I'd like to see is a full tutorial/article showing all the steps necessary the gory active directory sections and all to facilitate a company wide jre rollout. After all we're Java people not MS admins what I need is something to give to the customers administrator who all too often it seems claims ignorance of active directory rollouts.

  The elevated privs is important in making the rollout far smoother and all-round successful, but some documentation and marketing of the principals can still be helpful - doubt many java developers even know this is possible. A Frontpage article, j2se docs and maybe even a technical tips newsletter would make me happy.

  Even better would be confirmation that the same technique is possible even if you've got a Linux box serving the Windows domain (like we have here).

  Posted by: osbald on May 17, 2005 at 03:42 AM

• While I'm glad to find out that the JRE can be as little as 7 MB instead of 15 MB, I strongly agree with osbard regarding the importance of installing an app&runtime with the least fuss possible. If you've worked on GUI apps for a long time, there is a chance that you really care about ease-of-use issues. I complained in "Why don't you ship Swing apps" that Sun doesn't have a culture that encourages Sun programmers to make the extra effort to make life easy for users, and the jre installation process demonstrates this. 90% of the way there always seems to be the completion point for Sun, and it's this "almost there is good enough" culture at Sun that causes lots of frustration. I'd like to just download the combined app and jre, and then let it install itself in one-step and with as little user involvement as possible.

  Posted by: ssinai on May 20, 2005 at 06:05 PM

• You're still not understanding the app distribution/JRE download size problem -- the online installer doesn't fix it, incremental patching doesn't fix it, the offline installer doesn't fix it, and WebStart doesn't fix it. (Or maybe I don't understand and you can explain this to me.)

  Here's the issue: the only acceptable way to distribute a commercial desktop java application is by bundling a JRE. Period. And a bundled JRE is large. (It adds ~28mb to my installer made with Caphyon's AdvancedInstaller, none of the tricks in Stanley's blog seem to help.)

  Bundling is the only way to know that your application will continue to run correctly on the user's computer, regardless of any other installs in the past or the future. It's the only way to keep from screwing up any other java apps that the user may install in the future. There's a term from Windows programming called DLL Hell, which Sun seems to be trying very hard to re-invent in javaland. You have to understand: in Java, when you _test_ against a particular JRE version on a particular platform, you must _run_ against that JRE version on that platform, from now until the end of days. There's no way that you can guarantee me that my app, developed under 1.4, is going to run correctly with no changes under 1.6 or 1.8 or whatever.

  Here's the nightmare scenario:
  1. User installs my app with a centralized 1.5 JRE using the online installer. It's an unhappy installation experience because there are 2 installers with different messaging and design, mine and Sun's, but he deals with it. Eventually he gets it up and running, loves the app, uses it every day.
  2. Next year, User installs a new Java app, which upgrades the centralized JRE to 1.7.
  3. User runs my app, and it breaks, or just as bad, looks different. The user didn't touch my app, so why did it change behavior? Unless the user is a Java programmer, how is he going to figure out what happened?

  Don't think this happens? I just experienced it, since I haven't found a way to bundle the Mac JRE. (Is there a way? Please tell me!)
  1. I've been writing against 1.4 because I want to target both Win and Mac, and the Mac was (until last week) stuck at 1.4x.
  2. My alpha version uses Jidesoft's Action Framework to show menus and toolbars. It's great on Windows, but I had to make modifications to my code for the Mac menubar. That's fine, I expect the Mac to be different.
  3. It looks correct under OSX 10.3 + JRE 1.4. The menus are at the top of the screen, outside of my MDI window.
  4. My friend tried it under OSX 10.4 + JRE 1.5, and asked why the menus are smushed down the left side of the window? I only have one Mac right now, and I want to keep it on 10.3 + 1.4, so I can't even SEE the problem!

  Happily, this was caught this in a very early phase for my app, and I'll have time to get multiple Mac environments and test/fix it before launch. But what happens after I launch it, and users (hopefully) install and run it? I find myself terrified of OSX 10.5 and JRE 1.6. The only reason I'm not terrified of Java 1.6 on Windows is that I can bundle my own JRE, and not have to deal with it.

  If I do my job really well, my app will work correctly, and keep working correctly, regardless of whatever else happens to the user's machine. MSWord doesn't get wonky when you install Photoshop. But I need help from Sun to make that happen.

  If this sounds like a rehash of Joel Spolsky's rant about needing a static linker for .NET, well, it is. The main reason I chose to develop my product on Java instead of .NET was that I could embed the JRE, saving me DLL/Runtime Version Hell and the associated infinite, install-by-install support costs. I have to take the hit on download size, but at least that's a finite, universal problem. And I'd love some help from Sun on that front!

  It's a different story for internal enterprise apps and programmer demo apps, whose users have different abilities/needs. I'm only speaking for commercial, end-user-oriented product developers that want to sell on the web.

  Posted by: vineelshah on May 21, 2005 at 01:34 AM

• I'll have to add on to fonts, fonts, font!

  I wish subpixel rendering would have been in Java 5. It's just hard to stomach Swing fonts on an LCD.

  Posted by: davelopez on May 28, 2005 at 03:46 PM

• Earlier I posted a comment about how it's easy to do common things in Swing, but once I try to do something different, Swing puts up pointless roadblocks. I just encountered a very clear example while trying to write a custom JMenu.
  I want a JMenu filled with a dynamically adjusted list of items. Every time the user pops up the menu, the number of options may have changed. Each item has essentially the same action (only the data differs), so this should be trivial. I should be able to override a few methods like getItemCount() and getItem(int ii). While this might not be a common task, it's the sort of thing that Object-oriented inheritance was created for, so it should be easy to do.
  Unfortunately, JMenu delegates these tasks to a private member of class JPopupMenu. It's instantiated in a private method, and it's always accessed directly, so there's absolutely no way to override it. I could override each method that calls it, but the updateUI() method makes this task even more complicated.
  Furthermore, the Swing team extracts absolutely NO ADVANTAGE by doing it this way. It's just a poorly thought-out design that gives us functionality without any real flexibility.
  If I were to submit an RFE to fix this, I know exactly what would happen. Nobody would vote for it, because it's not often needed, and the Swing Team would eventually close the RFE for lack of interest. There are two problems with this logic. First, it’s a TRIVIAL fix. All they need to do is put the code to instantiate the JPopupMenu into a protected method. Second, a good API should encourage people who travel off the beaten path. It should open up new avenues for development, not close them off. Swing easily supports the dry, run-of-the-mill business applications that make no creative demands on the UI. But if I have a unique application that calls for new UI paradigms, Swing is a disaster! In short, Swing inhibits my creativity.
  

  Posted by: miguelm on June 22, 2005 at 05:41 PM

• The problems with Webstart, compared to HTML/Javascript/AJAX thin client apps are that: (1) Webstart apps are actually thick clients, (2) they require programming skill (a web designer usually won't write any Swing code), (3) they require compilation+packaging every time you deploy even for testing, (4) Interaction with the server is complex compared to how it's done in HTML with forms. The XAMJ Project (xamjwg.org) attempts to address this, and at the same time it's a response to Microsoft's .NET-based XAML.

  Posted by: xamjadmin on July 08, 2005 at 01:16 PM

This work is licensed under a Creative Commons License.