In a recent blog post, Daniel Steinberg argues that Java on the desktop was a missed opportunity, and that those in charge of Java SE still poorly understand the needs of desktop users and consumers. The solution: outsource Java SE development to a company that has always excelled at creating successful consumer-focused environments.
Among the longest running debates in the Java community must surely be the often sore subject of desktop Java. While most developers learned of Java from the figure of Duke dancing inside an applet, it soon became obvious that creating successful Java desktop applications, let alone applets, was no easy task. Instead, Java took off on the server, leaving some to wonder if anyone cared to develop desktop applications any more, given especially the recent tide of more capable browser-based widgets and Ajax.
At the same time as Ajax is taking off, however, desktop environments are about to reach a new level of features and usability with the upcoming release of new operating system versions, such as Windows Vista. Developers will have to be able to take advantage of new desktop features in order to satisfy users' expectations.
If desktop Java is to become a competitive environment, it must not only make it possible to develop powerful desktop applications, but also make the development of high-quality desktop apps easy, argues Daniel Steinberg in a recent blog post, Outsourcing Java SE. Yet, such a consumer-focused version of Java may not be in the purview of Sun's engineering talents, according to Steinberg:
In the first iteration of the GUI [in Java 1.0], Sun ignored the user experience. In this second iteration, the beginning of what would be called Java 2, Sun provided developers with everything they would need to deliver an attractive, performant application. They just didn't make it easy. I would argue that in both cases the cause is the same and still exists today: Sun does not build end-user applications. They are not consuming their APIs.
Microsoft and Apple are both in the business of creating and selling operating systems. But both companies also make applications that sit on top of these operating systems. No one knows more about programming on the Windows platform than the Office team. What a great source for feedback.
Steinberg points out Java may be considered a sort of operating system platform that applications are written to, and that,
Having a consumer products division strengthens the operating system in five important ways. 1) It provides feedback on the OS and its implementation. 2) It uncovers features that should be added to the OS. 3) It highlights the power of the OS. 4) It challenges other companies to innovate on top of the platform as well. 5) End users will pay for good applications.
Because Sun lacks such a division, it has missed many opportunities to capture consumers' imagination, says Steinberg:
How many things have Sun missed because they didn't see the possibilities? If Apple were running Java, the media frameworks would not be in disrepair. With podcasting as popular as it is, Sun could have funded work on the media frameworks by building an app for creating podcasts or for aggregating and viewing them in some different and compelling way.
...When Sun creates desktop APIs, why are the first two platforms targeted and released Solaris and Linux? If you are creating desktop technology, shouldn't you be targeting Windows and Mac first?
Steinberg's solution is for Sun to outsource desktop Java to a company that has proven itself time and again to be able to deliver compelling, consumer-focused desktop environments and applications: Apple.
Apple uses class sharing and natively rendered menus. This makes Java applications pretty snappy on OS X. Windows and *nix now has class sharing (based on Apple code), but menus are written as part of the application. This gives you a millisecond slowdown every time you enter a menu. This slowdow can be huge if the application rendering code is of poor quality (which is the norm) This and the fact that JFC/Swing is fancy-stuff-off-by-default (like repaint on resize, pretty fonts, look and feel) contributes to the notion that "Java on the desktop is dead" aka "Java sucks".
Personally I think J2SE kicks ass. I am a one man shop and I can create stuff like this (plug) http://us.teppefall.com/whitepaper,470,0.jspn on a tiny budget. Sun was pissed at Microsoft and J2SE on Windows suffered visually because of it. Tough noogies. I am a bit tired on nuking the JVM though. 1.5 crashes a lot on OS X and Windows.
Apple is already making Java better. Jet-another-widget-project - Google, Yahoo, Opera, IE ActiveX, Applets, Dashboard, etc does not make my menus render any faster. MP4/AAC support would be nice though.
And by the way.. I have Dashboard turned off on my Powerbook. I need the memory to run other applications.
I think the opportunities for making the UI experiences better are massive but I don't think Sun have tried that hard.
Just look at how bad that Java webstart UI is. I can't believe that in 2006, you still get this tacky UI without even a trace of anti-aliased fonts. It's real Windows 3.11 stuff. This might sound rather superficial but I think it really impairs the user's perception of the application they are about to experience, no matter how good it performs.
> Personally I think J2SE kicks ass. I am a one man shop and > I can create stuff like this (plug) > http://us.teppefall.com/whitepaper,470,0.jspn on a tiny > budget. Sun was pissed at Microsoft and J2SE on Windows > suffered visually because of it. Tough noogies. I am a bit > tired on nuking the JVM though. 1.5 crashes a lot on OS X > and Windows. >
I also think that J2SE's desktop features are very powerful, and my understanding is that Swing provides a lot more features than comparable windowing toolkits do. I agree that the problem is that in Swing the nice features are turned off by default - you have to hunt for nice L&Fs or other features, and even font anti-aliasing is an option in JDK 1.5 (you get automatic anti-aliasing on Sun's JDK if you specify the -Dswing.aatext=true option). And the default Swing L&F is so awful that anyone seeing that the first time will think it's a throwback to Windows 3.1.
There is much room for improvement, but I don't think Sun entirely missed the boat yet on desktop Java. Ajax may have whetted the apatite of users for a user experience more sophisticated than plain HTML can provide in many application categories. Yet, while there is much talk about Ajax, and there are fancy Ajax apps and toolkits out there, the fragmentation of the browser landscape is guaranteed to ensure that building usable Ajax apps will remain hard for a long time to come.
As an example, I was surprised to find that IE 7, now in beta, does not support CSS 2. So if you write an Ajax app with CSS 2 support, you have to write a version for IE7, too, that gracefully degrades to CSS 1. I'm sure there are many other differences between just Firefox and IE 7 that will make writing a truly cross-browser Ajax app rather hard. And then there are other browsers, too.
That leads me to think that only companies with large amounts of resources (or lots of time on their hands) will be able to make their apps work on all those browsers. Others will have to look for a more effective user interface toolkit for non-trivial apps, and Swing looks like an excellent possibility.
So, yes, Sun should - must - outsource desktop Java to whoever can make it better - be that Apple, or even Microsoft.
I think, and this is pure speculation, that the reason why JFC sucks so much per default is their Sun Ray platform. Since everything is done over ethernet, stuff like fancy gradients and pretty shadows requires more bandwidth and processing power on the server.
> I think, and this is pure speculation, that the reason why > JFC sucks so much per default is their Sun Ray platform. > Since everything is done over ethernet, stuff like fancy > gradients and pretty shadows requires more bandwidth and > processing power on the server. > > http://sun.com/sunray/ > > JFC was probably designed for VNC-like systems. Hence the > suck factor.
Well, I don't that had anything to do with that, if only because the Sun Ray came out after Swing.
"The Sun Ray was introduced by Sun Microsystems in 1999 ... Rather than using the X Display protocol, Sun developed the separate secure bitmap-based network protocol "ALP" (Appliance Link Protocol) for the Sun Ray system (which is similar in concept to VNC)." http://en.wikipedia.org/wiki/Sun_Ray
The big problem is that Sun doesn't write applications. They create operating systems (projecting standardized APIs) and they create Java simplementations using standardized APIS. Only recently have sun engineers started to understand how far behind the curve they actually are in terms of understanding the work before them.
They'll probably miss the boat completely, and the gnu classpath project will probably come out with something that works well enough for most desktop apps in the next year or so.
Heck, I've had a bug parade entry open since last decade to try and get them to provide a simple iterator interface to File.list() so that large directories weren't loaded in their entirety before you could see the name of one of the files. But they think its more important to make the server apps work fast.
There are probably 100,000 top dollar opportunities for server class customers, world wide (maybe only 10,000). But, there are a billion opportunities to make somebody happy with a small desktop app that is useful.
I've done a lot with Java over the years. It's getting better. But, the attention to the desktop has got to go up by an order of magnitude. The applet/jnlp environment is not the answer. The real answer is Jini and ServiceUI deployed clients. Then, you get to have full blown access based on security policy that can be deployed dynamically.