Welcome!

Java Authors: Al Mannarino, Christopher Keene, Anatoly Krivitsky, Pat Romanski, Jason Weathersby

Related Topics: Java

Java: Article

It's Not Over Till the Fat Client Sings

It's Not Over Till the Fat Client Sings

Reports of Java's death on the desktop may be somewhat premature. A recent Giga group report, "Return of the Rich Clients", predicts that in the next three years browser-rich clients will grow by 350%, stand-alone clients by 250%, while HTML will decline by 50%. Two major facts are contributing to this change: problems associated with traditional client development being solved and HTML not providing a powerful enough user interface for all GUI requirements. Both of these are good news for Java.

For stand-alone clients, Java has advanced on several fronts recently. The J2SE team delivered substantial performance improvements to Swing in 1.4.2, as well as a great Windows XP and GTK look and feel. Meanwhile the Eclipse project created SWT that uses a rich set of cross-platform native controls over and above those provided by AWT. Newsgroup flame wars often pitch the two as rival GUI toolkits; however, hopefully this will become a thing of the past as the current interoperability problems are tackled.

One of the problems associated with traditional client/server development is a systems management issue of how to ensure that the software at all end points is kept up-to-date. HTML largely avoids this by creating the page marking up the client UI each time a request is made to the Web server. Arguably, this on-demand preparation of the GUI is the single largest reason HTML has become such a ubiquitous programming model. Java Web Start, however, solves the original distribution problem by using the Web as a mechanism to deliver a traditional Java application to the client. Each time the program is run it checks against the Web server to see whether a newer version is available and, if required, downloads the updated JAR files. JWS programs run within Java's security model; however, client-side caching and the use of local JRE avoid the issues that plagued applets.

Several Java hybrid clients also exist that run Java on the server, but instead of delivering HTML to the browser, they use plug-ins to create a richer UI experience. With the ultra-lightweight client from Canoo, a J2EE programmer uses Swing peer classes as if writing client-side Java, requests are marshaled back and forth as XML, and a full Swing GUI is actually created on the client. The RSWT SourceForge project does the same except it uses SWT as its Java toolkit. Other examples of Java hybrid technologies are classic blend, droplets, and thinlets, all of which deliver a rich GUI to the user through a Java server-side programming model.

It's not going to be easy for Java to win back the client as it faces stiff competition from Microsoft with Windows Forms, and Visual Basic as the incumbent client development language.

With this level of activity in the client Java space, Java Developer's Journal is launching a new section entitled "Desktop Java." This will include solid technical content to help you understand more about the various projects and technologies, as well as editorials and news. The mistakes have been made, the lessons learned, and Java is now well positioned to recapture some of its lost pride as a GUI platform. We hope you enjoy the new section.

References
1.  "Return of the Rich Clients" report available to registered Giga customers: www.gigaweb.com
2.  SWT/Swing: Click Here!
3.  Java Web Start: Click Here!
4.  ULC: www.canoo.com/ulc
5.  RSWT: http://rswt.sourceforge.net
6.  Classic blend: www.appliedreasoning.com/products_what_is_Classic_Blend.htm
7.  Droplets: www.droplets.com
8.  Thinlets: www.thinlet.com

More Stories By Joe Winchester

Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.

Comments (4) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Frank Moseley 10/22/03 11:22:35 AM EDT

I am both a Java programmer and a Windows programmer, and my experience has shown Java will never be able to build anything more than a fair windows client app.

For example, spell checking is a must have in any good client app. Contrast the huge amount of coding needed to be done in the Java app compared to the few lines of Word Basic in native Windows app.

What do you say, when the user asked why the business specific words they entered in Word are not showing up in your spell checker?

For example, your application displays bitmaps and the user notices a flaw and wants to edit it. In the native windows app the user just right clicks on the bitmap, and the application menus turn into the ones in paint and the user does the edit, clicks save, and the application menus turn back. What do you do to make your Java app do that?

For example, your application organizes files and have preview capability for text, sound, and video files. Native window apps can have the windows media player do it with a single fuction call.

And so on...

John Small 10/07/03 08:06:25 AM EDT

Is you look at Flash and consider
later versions of Javascript and
DHTML you can send and receive
hidden forms and thus of a thin
client now that does not jump
pages but rather looks and acts
like a desktop client. You can
do this cross platform too. And
a functional reactive specification
of GUI layouts and wirings are about
1/10 the size of an OO specification.

Christopher Stura 10/07/03 01:55:03 AM EDT

There was one wonderfull thing about HTML clients (they did not only work under windows!) the world is moving into new operating systems (OSX,Embedded devices, Linux, etc) java runs there where .NET does not and this is why only Java clients can replace HTML thin clients. .NET cannot offer the technology needed to satisfy all the requirements made by users. Now just immagine if you sold a web site to a graphics studio which already invested $1000'nds of dollars in MAC and SGI and you wrote a thick client with .NET. I guess you can't sell them your software because they can't use it!.

Jwahar R Bammi 10/06/03 08:05:05 PM EDT

How can you even begin comparing the improved Swing or SWT to .net Windows forms. You've got to be dreaming. Yes, fat clients are coming back, but not with the offerings Java currently has to offer. Java on the server, taking SOAP with .net fat client is much more believable. Yes, i live in both world, and yes i objectively can compare the two, and their strengths