Is Client-Side Java Dead?

maverick2003 asks: "Just while I was thinking that client-side Java is well and truly dead, here comes along a project, a really large one to boot, that involves developing a 'rich Java based client'. While I'm sure that given the right resources and time-frame, this is certainly possible, I was wondering what kind of experiences the Java community has with developing large Java client side applications. Five years ago, Swing and Java client technology had light-years to go before matching up with native Windoze APIs. Getting Swing to do exactly what you wanted, was a guaranteed trip into pure hell itself, with all sorts of weird bugs and workarounds to deal with. The applications that I've developed since then uses VB/VC++ and will talk to a Java server. This has gotten much easier nowadays with SOAP libraries available for cross-platform stuff. Have things improved since then? If yes, by what degree?" What would you use as an example of a large-scale, real-world, high-quality client-side Java application?

Comments

Java is pretty mature

[ObviousGuy]

Sure, it's not popular or common on the client-side in either application or applet form, but it does exist.

Most operating systems ship with some sort of Java VM, you should be able to deploy wherever you want and expect at least some support.

Sure, it's neither as fast as true binary code nor is the GUI as pretty as native apps, but if you wanted those you wouldn't be thinking about Java in the first place.

Java is as dead as Perl on the client. It's dead to all those who don't use it, but for those that do, it's indispensable.

Quality Java Client Apps are possible

[redelvis]

I've been writing Client side Java GUI programs for about 3 years now. Some have been small interactive graphing tools, but more recently I've been working on a large Debugging Tool API program. In my experience, it is possible to create Swing applications that are:

• Visually pleasing
• Fast and Responsive
• Scalable

However, I have found to achieve these goals at a high level of quality has taken significant experience and many dead-ends. Java Swing GUI's are NOT for "rapid GUI application" the same way that VB is marketed as for instance. It takes solid knowledge of the Swing API - which in my opinion is a very powerful flexible GUI API, but one which comes with lots of "gotchas" to watch out for.

In my experience I would say that a good Client side Java GUI can be developed, but the following pitfalls need to be avoided:

• Avoid GUI Code Generator tools to design your GUI layouts. They lead to highly unmaintainable GUI code but more importantly to less consistent screens (have a read of Building user interfaces for object-oriented systems for more details
• Build a decent framework that sits ontop of Swing to automate and standardise the process of view creation. I've found Swing GUI work can be made significantly more productive and easier to maintain if Swing screens are being automatically generated from data objects. For example, I use a Field builder to generate appropraite Swing fields (text box, combo box, check box etc) depending on the Type of the data field (String = text box, Boolean = check box etc). This way the interface remains constant and up to date with any chances to the data model.
• Know when to deligate work to a background thread, instead of tying up the AWT Event thread ... this is a common mistake in Java GUI's that gives the perception of an unresponsive or frozen application
• For large applications, distribute a decent Java Runtime for your application to run on. This is the approach Borland takes with JBuilder. You are distributing a big app, so why not bundle with it a robust JVM that you have tested your app on?

Just my 2c - happy App building.