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 SwingThe 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.
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”.
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.
SummaryClient 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
|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|
|License||Sun License||Apache 2.0||Dual (Commercial /GPL)|
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.