Java and the Client, will they ever be happy?

April 10th, 2008 · Peter Paul Bakker · java, Software, thoughts One comment - Tags: , , , , , , , ,

In a recent interview (well, that’s a big word, I was asked a question about Java…) I mentioned that there is still a future for Java on the Client. But is there?

There are so many Rich Internet Application frameworks and solutions nowadays: Flex, Lazlo, Ajax-based, Silverlight, etc… it dazzles the mind. What to pick? Why learn yet another tool, configuration and/or language?

As a Java developer, would it not be wonderful to do everything in Java. Drop the XML configuration and remoting. No JSPs or inside-out HTML, tags with HTML, Javascript, XHTML, CSS, and what not…

And I was amazed with the requirements of web applications: master-detail updates, dynamic drop downs, complex grids with excel behaviour, drag and drop, tabs… and all the roundtrips that are needed to get things done. We’ve come a long way now (see Google apps), but I think there is still something to be said for plain old Java GUI’s.

That was the entry point for a little project that I wrote. I’ve tagged it the “290% Java project” (stole that from the Oracle statement of a couple of years ago: “300% Java…”): Java in the Data layer, the Application Server layer and the Client layer.

How to accomplish this? Create a Swing or RCP “lite weight” client. Make this available via Java Web Start. Communicate simple POJOs via the Burlap and/or Hessian protocol, using a Servlet in Tomcat Server. Also use those protocols to store the data on disk (no database!). The remote server calls are defined by a clean Java interface. To create a Swing UI use a tool such as JFormDesigner (I hear good things of Matisse nowadays).

The client app runs both on Windows and the Mac, using Java 5 or 6.

This app is now being used for almost 2 years in a row, daily, both at home and at the workplace by around 10 people. It is like a bulletin board for a group, that is closed. Everybody in the group can read all messages, but you can specify who the message is intended for. Furthermore, it shows you directly if the message has been read by all that it is intended for (a feature that I did not come acros in email or other bulletin boards), and when it was read.

It was such a pleasure to create a UI in Java after all the struggles in the Browser world.

I presented this approach to a group of Java developers. I was surprised to learn that there is fear to start using this “all Java architecture” approach. The reasons being that there skills to program Swing or RCP are hard to find, JSP and JSF programmers are much easier to find. (Is this true?) Also, Swing seems to be considered hard to do and still has a reputation of being slow. Well… look at NetBeans; great job for a Swing ui! I just love the MVC model of it.

Some other points:

  • Rolling out a new version of the app is as simple as installing a new server side app: just put the news jars on a central site and Java Web Start will automatically get that new version when users open the application.
  • You can make a shortcut from the desktop to a JWS program.
  • You can use the same POJO model for your data on the server and on the client.
  • The model can be effectively cached in the client app. You can make it smart. In my proof of concept there is a version check of the model on the server. If it has not been changed, there is no need to refetch it. If it has changes (e.g. new or updated messages), only send the delta.
  • You can make use of third party jars on the client machine. For instance to generate PDF docs on the fly using iText. This relieves the server of a lot of memory and processor consumption.
  • You can make truely amazing interfaces using Java 2D, Java 3D, jGoodies, and maybe even JavaFX (there is a JavaFX demo on the Hessian RIA page, I discovered recently!)
  • You can use peer-to-peer architectures to communicate via clients directly (a la Azureus :-) )

    • There are some things to be aware of, or “some interesting issues”:

  • How to deal with security and authorisation.
  • How to secure your data over the line. Note that I used https for all communication. It even works behind corporate firewalls!
  • You need to sign all jars to make communication available, or file system access. Not a big deal with a few lines of ant script.
  • You also need to sign with a trusted certificate, so you will not get annoying popups during the app startup. These are quite expensive for a proof of concept (couple of hunderds of Euros). Although you can use a free Thawte personal certificate that is intended for e-mail.
  • There are some caching issues with JWS. Workaround that by putting version numbers in the jnlp filename or url.
  • What about using a very lite weight jump start client, based on Rich Client Platform of eclipse? You would only need Java Web Start for that little client. And then you can use the OSGi plugin model to dynamically load your app (or portal like app!) with the already present upgrade feature in eclipse.

    • All in all, I really like this concept. Who dares to make the jump??? I think it is really suited for intranet apps that have complex GUI requirements, and need to be very responsive…

    Let me know!