Evaluating Java Web frameworks

Over the last few years, there has been an enormous increase in the number of Web frameworks available to Java developers. Due to this, choosing one to standardise on for an organisation (or even just for a project) can be a difficult task, and often requires tradeoffs or compromise as each framework supports different features.

In this series of Industry Insights, I'll examine some of the most widely used, innovative and interesting frameworks currently available, and try to identify the strengths and weaknesses of each.

These frameworks have been grouped into a few broad categories, though it should be noted that this is just a rough guide, and substantial overlap exists.

These frameworks rely heavily on Ajax to achieve a very rich, desktop-like user experience delivered via the browser. Developing for these frameworks often requires little or no knowledge of HTML or JavaScript, as the front-end is typically developed in plain Java. The framework then generates all the HTML and JavaScript required by the front-end.

This approach has some significant benefits, such as the fact that cross-browser compatibility issues are largely solved by the framework. Furthermore, the code often resembles AWT or Swing, both in terms of the components used, and in reacting to user actions by employing action listeners or other event-driven mechanisms not generally found in other frameworks.

Often these frameworks require few or no page reloads, as components are added and removed individually from a "desktop" using Ajax only.

Frameworks

GWT, ZK, Echo, OpenLaszlo, Backbase

Advantages

* Provides a rich user experience, similar to a desktop application
* Requires no Ajax experience, and little or no HTML experience
* Could often feel familiar to Swing developers
* Full page reloads not required often
* Provides large component libraries
* Cross-browser compatibility issues largely solved by the framework

Disadvantages

* Long page load times when the desktop loads for the first time
* Requires lots of server communication
* Memory overhead on the server to track front-end state and user objects
* Very difficult to implement front-end unit testing. This is often not supported at all, as a full server environment is required to behave correctly
* Difficult to switch to other frameworks, as all the front-end code is framework specific
* Could be more difficult to style to exact requirements as HTML is generated. As with desktop applications, these frameworks tend to have a 'typical' look and feel associated with the framework

When to use these frameworks

1. If you have very complex front-end requirements
2. If your application relies heavily on Ajax, and you don't want to write all the plumbing code yourself
3. If the initial page-load time does not need to be very fast

This is a feature-rich framework that takes an unusual approach. Development is done in pure Java using a subset of AWT (version 1.4.2), which is compiled into pure HTML and JavaScript. The HTML files can then be hosted on any Web server, such as a plain Apache server. This means the entire front-end runs on the client machine, possibly making this the most lightweight framework on the server side of all the frameworks in this category.

There has been an enormous increase in the number of Web frameworks available to Java developers.

Andre van der Schyff is a senior developer at DVT.

However, the compile step also has some unusual side-effects. Most noticeably, in order to debug applications during development, the application needs to run in a special browser, called hosted mode. In this mode, the code is not compiled to JavaScript, and developers can debug with any IDE.

The RPC (remote procedure call) mechanism is also quite awkward, requiring two almost identical service interfaces, and an implementation class that extends a GWT class. This may affect the application architecture as it cannot be used on its own base classes for service implementations.

Strengths

* Very feature-rich
* AWT has a low learning curve
* Proven by applications such as Gmail and Google Reader
* Compile step produces a fast user experience
* Lots of client-side processing
* Dynamic binding: makes use of particular browser features

Weaknesses

* Awkward service call mechanism
* Requires a custom server/runtime for development
* AWT compatibility is a subset of 1.4.2
* Requires familiarity to know which AWT features are supported

* In the next Industry Insight, I'll look at ZK and Echo and begin looking at component-based frameworks.

* Andre van der Schyff is a senior developer at DVT.