Bringing Swing applications into AJAX world with GWT and AjaxSwing
Java Swing had its ups and downs but throughout its 10-year life it has achieved maturity and an established share of the user interface marketplace. While its long-term future is up for a debate and the momentum is clearly not with Swing, this UI technology continues to thrive in Java world which is evidenced by a large number of existing applications and very active community forums. There are hundreds of applications written with Swing that are used daily and need to continue to be maintained.
This article tries to address the two main questions. What is the future of Swing applications and how can they be brought into an AJAX world that relies solely on the browser as a deployment platform?
Java Swing
The main challenge to Swing applications continues to be the requirement to have a compatible JRE on the user's desktop. Java Runtime Environment has gotten leaner over the years and technologies such as Java WebStart and Java Plugin for the browser improved the distribution model. However, expecting every user to have a compatible JRE is still unrealistic and some desktops may not have Java runtime at all. So while developing both the user interface and the backend logic in Java is very clean and productive, deploying Java Swing applications is significantly riskier then deploying web based user interfaces.The other disadvantages of Swing-based user interfaces are inability to mix content of Java applications with content from other applications in an enterprise, a task easily accomplished by portals and HTML mash-up technologies. There is a preconceived notion that everything non-browser based is inferior to pure HTML front ends, so selling Java Swing to the management and enterprise architects is often an uphill battle.
Certainly, there are certain kinds of applications that are still hard to do using pure AJAX. Anything that needs to produce graphs or generate images at runtime is not possible to do in JavaScript leaving Swing as a viable choice. But many of the Swing applications where developed in enterprises for database querying and CRUD operations (create/read/update/delete).
Together with client-side Java, Swing has been loosing the momentum every year since Sun-Microsoft rift. There haven't been any major updates for the last 6 years and reportedly Sun has pulled the plug on whatever little Swing improvement initiatives there were. JavaFX was supposed to breathe new life into client side Java but that is not happening either. On the front end Java has to compete with Flash, Microsoft Silverlight and AJAX, the dominant stack of technologies that have matured to a point where they are comparable to thick clients. Java, like Flash and Silverlight, do not offer enough advantage over AJAX to justify the requirement of client side installation of a runtime environment. It is becoming more and more evident that pure browser technologies of HTML and JavaScript will continue to dominate the client landscape in the foreseeable future.
Now that we have answered “what is the future of Swing applications” question, we can address “how can they be brought into the AJAX world”.
Google Web Toolkit (GWT)
HTML was never designed for building dynamic user interfaces, and JavaScript was never designed for implementing large applications. Using HTML and JavaScript to build application user interface is cumbersome and unproductive exercise. More then 10 years since the emergence of dynamic HTML sites, there is still no technology that offers good layouts, components and application development foundation.GWT is a breakthrough technology from Google that allows development of the entire application in pure Java. The user interface is built using Swing-like components and simple layouts, and then it is compiled into a JavaScript executable file that is embedded in HTML page. During the construction the developer only deals with Java, and there is simulated mode that allows testing without doing the full compilation. GWT implements most of the core Java APIs and there is a fairly straightforward way of invoking Java services from the user interface. GWT takes care of browser compatibility and optimizations by producing different compiled versions of the application for different browsers.
A great advantage of GWT over the traditional HTML generation frameworks such as Struts and JSF is that the user interface code runs in the browser. This means that the user is given instant feedback and the UI logic can be executed without making an HTTP call to the server. Unlike Swing, GWT front end is deployed as JavaScript so users are not required to have a compatible JRE.
While GWT is an amazing technology with a bright future, it has its own shortfalls. There application has to follow GWT structure and the developer has to be aware if the code executes on the client or the server. Not all Java methods and APIs are implemented, there is no support for dynamic linking and building modular applications. It is not possible to have shared libraries and the entire application has to load before it can be executed. Another issue is that GWT UI components are not based on AWT or Swing. the class names and methods are different, layouts are conceptually closer to HTML then Java and event handling mechanisms are based on JavaScript events. This makes it easier to compile client code into JavaScript but it introduces a learning curve to Java developers, and makes migration of Swing and AWT applications to GWT impossible.
AjaxSwing
Another technology allowing the development of both client side and server side layers of the application in standard Java is AjaxSwing. This toolkit takes a standard Java Swing-based applications and dynamically generates an HTML/JavaScript code that executes in the browser. Unlike GWT, which creates JavaScript code at compile time, AjaxSwing produces AJAX representations of Swing screens at runtime and emulates user actions from the browser back to the Swing applications.AjaxSwing has been developed for 8 years but only recently it has reached the maturity where all Swing functionality is mirrored in AJAX screens. The developer can build and test their code like any other Swing application. In fact, the applications can be deployed as standalone Swing clients or WebStart-based Java apps delivered over the internet. With AjaxSwing the application can also be deployed into a web server and accessed from the browser, just like any HTML/JavaScript based user interface.
The greatest advantage of AjaxSwing is that it requires virtually no learning because it works with standard Java and Swing. It can be applied to existing Swing applications to deliver them via a browser and remove the requirement to have a JRE on the users's desktop. AjaxSwing applications can run on mobile phones and devices like iPhone that do not have a JRE but have a fully-functional web browser.
Where AjaxSwing looses to Swing and GWT is in scalability and responsiveness. Because architecturally AjaxSwing is a server-side technology, most user action processing and event handling has to be delegated to the server, which by definition can not be as fast and execution of user interface logic directly on the client. Like most server-side technology AjaxSwing doesn't scale as well as client/server technology because of the greater per-user overhead.
Summary
Client side Java technology does not offer enough competitive advantage over AJAX and therefore is not likely to see any future improvements. Swing applications can be migrated or bridged with the AJAX world using pure Java technologies such as GWT or AjaxSwing. The table below helps to quickly grasp the differences between the three alternatives described in the previous sections| Criteria | Swing | GWT | AjaxSwing |
|---|---|---|---|
| Pure Java (no HTML/JavaScript/XML) | Yes | Yes | Yes |
| Compilable (runtime type checking, refactoring, early error detection) | Yes | Yes | Yes |
| Requires JRE on the client | Yes | No | No |
| Requires browser on the client | No | Yes | Yes |
| UI based on Java standards | Yes | No | No |
| Access to all Java APIs in the client code | Yes | No | Yes |
| UI development technology | Swing | Custom | Swing |
| Access to browser features and APIs | No | Yes | Yes |
| Usability in existing Swing applications | Yes | No | Yes |
| Ability to run on mobile devices | No | Yes | Yes |
| High scalability | Yes | Yes | No |
| Community Support | High | High | Medium |
| Future growth | Low | High | Medium |
| License | Sun License | Apache 2.0 | Dual (Commercial /GPL) |
From the industry experience and productivity perspective building applications in a uniform strictly typed language like Java offers a much higher productivity then a mixed environment where different parts of the application are implemented in different languages and technologies, such as HTML/JavaScript/XML/Java. The choice would probably be made for each organization based on the existing development skills and applications.
Organizations that have expertise in Swing and that have already developed applications based on Swing will benefit from continued use of Swing and can explore AjaxSwing for browser-based delivery.
Organizations without prior investment in Swing should consider GWT as the preferred choice because it's offers most of the benefits of a pure Java thick client without the requirement of a JRE on the user desktop. As GWT continues to mature the limitations of today will be overcome and the community support will increase.
