Skip to main content

All I've Got Tonight

Posted by editor on February 2, 2007 at 4:19 AM PST

Thinking in Java, but not on the client side?

Thinking in Java author Bruce Eckel's latest essay has the title Hybridizing Java, and by that he means developing Rich Internet Applications where only the server side is in Java. He starts by stating that "the web is a mess" with incompatibilities between browsers, and describing Ajax as "an excellent hack that gets the last bit of mileage from JavaScript", asserting that the end is in sight for what Ajax can do. A better client-side experiences is needed, and Bruce says "at some point we must ask why Java applets haven't become ubiquitous on the internet as the client-side standard for RIAs (Rich Internet Applications)."

The culprits he lists are many: a lack of pre-installed Java runtimes, a miserable experience for many who try to install it themselves, bad experiences with applets and Java applications (Bruce apparently uses the same horrible Memorex Swing app for making DVD labels that I do), inconsistent cross-platform behavior, the lack of a viable multimedia library, and more. To Bruce's mind, this litany of failure all but closes the door on client-side Java:

It's not impossible to build GUI applications with Java, but it's been 10 years and there are still installation hiccups with applets, Java WebStart, and regular applications. After 10 years, people don't trust it anymore. If it's not there after 10 years, then I'm going to go out on a limb and say that someone doesn't consider this problem important enough to fix. And even if they did, there have been so many bad experiences among consumers that it would take years to get the trust back.

So what's the alternative? Bruce's concept of "hybridizing" Java means to continue to use Java on the server side, but to move to Flash-based solutions for the client, such as Flex.

One of the most appealing things about Flex is that Flash was created with the idea of UI first. In a very real sense, it's a domain-specific language (DSL) for graphics, multimedia, and UIs, whereas most other solutions have been languages with UI libraries tacked on afterwards.

Moving beyond the browser, he points out Apollo, a cross-OS runtime that allows for creating desktop apps with Flex, potentially allowing you to write apps that work both in the browser and on the desktop.

Feedback to this article has been, as you might imagine, quite active. There are dozens of comments on the Artima post, a response from ONJava blogger Paul Browne that calls for a solution that degrades more gracefully than Flash, and further commentary on InfoQ's write-up of the story.

But what do you think? Does Bruce make the case for giving up on client-side Java, and is Flex really the best alternative today? Are Java's installation, behavior, and multimedia problems really insoluble in the short term? Think about it and let us know your opinion.

Apropos of the debate Bruce has started, the latest Poll asks "What do you think is the most practical client technology for Rich Internet Applications?" Cast your vote on the front page, then visit the results page for current tallies and discussion.

In Java Today,
the sqlb project has graduated from the incubator to a Java Enterprise Community Project.
This project, based on six years of ongoing development, makes Portable SQL a first-class Java citizen. SqlB is a pragmatic solution to java persistence, providing the richest possible SQL functionality while still working across all supported databases (including Oracle 9 &10, Microsoft SQL Server 2005,
Sybase ASE 12.5 & 15, and more). It supports compiled SQL, allows full spectrum SQL, EJB 3 entities, and much more.

Perhaps the third time will be the charm, as JSR 310 proposes a new "Date and Time API" to address the deficiencies of Date and Calendar. "The new API will be targeted at all applications needing a data model for dates and times. This model will go beyond classes to replace Date and Calendar, to include representations of date without time, time without date, durations and intervals. This will raise the quality of application code. For example, instead of using an int to store a duration, and javadoc to describe it as being a number of days, the date and time model will provide a class defining it unambiguously."

In today's Forums,
enicholas updates the thinking behind the "modular JDK" proposal in
Re: Java Kernel. How it is? When it will be part of JSR ?
"The fact that people want a stripped-down JRE and, being open source, we can't stop them from doing that is one of the driving forces behind this. By providing our own implementation, we hopefully reduce the impetus for people to do this themselves, and then we have folks distributing a 100% compatible version of Java complete with Plug-In and Web Start support, rather than a half-formed monstrosity which cannot be called Java."

Joshua Marinacci discusses the new Swing Application Framework in
Re: JSR296:
"JSR 296 will not provide the same thread tricks that foxtrot and spin do. JSR 296 is more like SwingWorker, but a lot easier to use. On the other hand, the EDT still works the same way so there is nothing which would prevent you from using Foxtrot or Spin in an application which also uses JSR 296."

adamman71 is hoping to find some
Documentation for JXTA 2.4.x?
"I am trying to understand how to use JXTA 2.4.1, but the class structure and organization is quite different than in JXTA 2.3.x. I have been searching for the equivalent of JxtaProgGuide_v2.3 for JXTA 2.4.1, but I could not find any such document. I am currently reading the javadoc provided for each class, but it is far from obvious to get the whole picture (especially for the newbie to JXTA that I am...) Does anyone have a 'global' document explaining how classes interact with each other in JXTA 2.4.1?"