Screaming Penguin

I was having a beer with Josh a while back and we were discussing the state of several Java technologies. He is going to work for Sun on the Swing team, so he is now fully vested in the Java Desktop (as in where it runs, not the Linux distro) vision. I have done damned few heavy-client apps in Java. Only 2 that were ever actually deployed to users, and they were both pretty basic. The thing is, aside from the flagging support on the Mac, developing Java desktop apps is pretty damned great. Java Web Start is perhaps the single greatest thing to come to Java, ever. While people get caught up on the "neat" of having the installer and the icons and the froo froo, I think they miss out on where JWS really changed things: Multiple JREs. For years, especially on a Win or Mac system you could only have one "real" default JRE. That meant an executable JAR file would always run with what the user had. JWS changed this, so now the user might have ever JRE on their system, but the system executes with whatever the one the app was built against, and knows how to get JREs it doesn't have. This breaks the need for a whole chain of really bag legacy stuff hanging around in the Java codebase... such as not defaulting SWING to the host OS LAF manager for one, simply because you don't HAVE to have backward compatiblity. Moreover, JWS's provisioning means that stuff just updates. And that is the way it should be. I assume many of you have read Mark Lucovsky's comments on Microsoft as a MS-Google convert. He talks about "shipping software":

Being a 16 year Microsoft veteran, a Distinguished Engineer, key architect and code writer for windows, architect of the largest source code control and build system ever attempted, I deeply believed that Microsoft knows how to ship software. We know how to build it, test it, localize it, manufacture it, charge lots of $$$ for it, etc. Mark and I talked about this briefly at lunch that day, and I have been thinking about it from time to time since... I am not sure I believe anymore, that Microsoft "knows how to ship software". When a Microsoft engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? I know the answer and so do you... The software sits in a source code control system for a minimum of two years (significantly longer for some of the early Longhorn code). At some point, the product that the fix is a part of will "ship" meaning that CD's will be pressed and delivered to customers and OEM's. In best case scenarios, the software will reach end users a few months after the Release To Manufacturing (RTM) date. In many cases, particularly for users working in large corporations, they won't see the software for a year or more post RTM... Consider the .NET framework for a second. Suppose you wrote something innocent like a screen saver, written in C# based on the .NET framework. How would you as an ISV "ship your software"? You can't. Not unless you sign up to ship Microsoft's software as well. You see, the .NET Framework isn't widely deployed. It is present on a small fraction of machines in the world. Microsoft built the software, tested it, released it to manufacturing. They "shipped it", but it will take years for it to be deployed widely enough for you, the ISV to be able to take advantage of it. If you want to use .NET, you need to ship Microsoft's software for them. Isn't this an odd state of affairs? Microsoft is supposed to be the one that "knows how to ship software", but you are the one doing all the heavy lifting. You are the one that has to ship their software the last mile, install it on end user machines, ensure their machines still work after you perform this platform level surgery. When an Amazon engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? What is the lag time between the engineer completing the work, and the software reaching its intended customers? A good friend of mine investigated a performance problem one morning, he saw an obvious defect and fixed it. His code was trivial, it was tested during the day, and rolled out that evening. By the next morning millions of users had benefited from his work. Not a single customer had to download a bag of bits, answer any silly questions, prove that they are not software thieves, reboot their computers, etc. The software was shipped to them, and they didn't have to lift a finger. Now that's what I call shipping software. I would argue that Microsoft used to know how to ship software, but the world has changed... The companies that "know how to ship software" are the ones to watch. They have embraced the network, deeply understand the concept of "software as a service", and know how to deliver incredible value to their customers efficiently and quickly.

This is a good point, and part of the reason why the "Browser as OS" arguement has come back up... a decade later. "Shipping" software is a big deal, and doing it well is important. Really, the more time that passes, the more I see something as simple as JWS as being what is going to really eat .NET's lunch at the application level. That ease of deployment and updating that doesn't require jumping through 16 hoops to make it work.