In his blog, Simon Phipps comments about a demo that Francois Orsini, Sun's Java database lead, gave at ApacheCon. The demo allows JavaDB—Sun's version of the small-footprint open-source Java database also known as Apache Derby—to persist data created in an Ajax application. Francois himself described the demo as follows:

It was all driven from the application scripting logic interacting directly with a ClientStoreService object. This last one is implemented in Java and acts as a controller to the local client storage (Derby). It is seen as an object from Javascript (LiveConnect technology) which allows me to access some client storage service to issue queries and get data returned in XML, parse/process it with the native scripting engine XML Dom parser.

Simon suggests that invoking Java classes from JavaScript, a technology that dates back to the Netscape days, have uses beyond storage:

AJAX applications will have increasingly complex needs, and returning to the server every time to have them met will become increasingly burdensome. So how about some slim local helper classes to make life easier? The J of AJAX - JavaScript - conveniently comes with the ability to treat Java classes as a platform-independent function library. Most of the platform variance we saw first time round with applets involved graphics, but helper classes have none. Most of the bulk first time round was graphics, but this time round the applets are pure code. Could be a perfect fit.

What might they do? Some obvious things, like encryption, compression, validation and so on. But also some more interesting things are possible. How about a tiny Jabber server so the applet can use the local IM client as a log or command prompt? Perform XML transforms (in conjunction perhaps with WADL) for multi-host compatibility? An embedded web server as per Mark McLaren? And of course, a local SQL database.

If invoking Java objects from an AJAX application became a real alternative, AJAX apps would suddenly have access to the entire Java API, including many third-party libraries. It has taken Java ten years and huge investments of money and labor to get to where it is, and it's hard to imagine that AJAX will provide a rich environment in the near future comparable to what Java has to offer today.

But are such background applets a real alternative? I always felt that the biggest problem with applets was their implementation—slow startup, incompatible behavior across browsers and platforms, and the need for users to potentially download a huge JRE to upgrade to the appropriate Java version.

It turns out that J2SE 5 already addressed many of these issues: Java WebStart and the Java Plugin now use a common architecture and implementation that allows seamless JRE updates and fast client-side caching of Java code. Applet startup time is still generally a problem, but some of that may be addressed in Java 6.

Simon's blog post hints at using Java applets in conjunction with AJAX—but what role would AJAX play in such a marriage? It's nice to persist HTML form data via an embedded Java database, but once we've incurred the applet startup time, why not display a Swing form that provides all the nice usability features that folks have invested time to design and implement over the past decade? Or use one of the Java look-and-feels to make the form look polished?

What role do you think a combination of AJAX and Java applets have on the client, if any? Will AJAX completely replace client-side Java? Or will AJAX and client-side Java co-exist, but in different applications, possibly even in different application domains?