Swing UI is mature while Ajax is still in its infancy
Suggest Ajax web development to a Java UI developer and you will invariably get the question “Why not Java RIA? I can do all this and more with Swing.” Is Swing as good as if not better than Ajax?
Marc Domenig, the CEO of Canoo has been in the Java RIA business for years. In this interview he talks about the Rich Internet Applications (RIA) space and why despite the hype around Ajax, Java Swing can be a much better option.
IndicThreads >> Hi Marc. Welcome to IndicThreads. Could you introduce yourself to our readers ?
Marc Domenig >> I’m one of the 18 guys who founded Canoo. Sporting the grayest temples, I’m serving as the CEO. We are a bunch of engineers who claim to understand something about object-oriented software: hence the name of the company. For the past seven years, we have focused entirely on Java-based consulting services and products.
“We have focused entirely on Java-based consulting services and products…”
IndicThreads >> Could you tell us about Canoo’s products in the rich internet applications (RIA) for Java space?
Marc Domenig >> Our flagship product is UltraLightClient (ULC). This is a Java library that enables using Swing in a server-side web architecture. As a result you get Swing Rich UIs for web applications that run on the server. The UI is rendered in a Presentation Engine that is independent of individual applications, and can execute both as an Applet in a browser, or on the desktop.
“UltraLightClient (ULC) is a Java library that enables using Swing in a server-side web architecture…”
Supplementing the ULC base product, we offer a point-and-click visual editor and a load testing tool.
IndicThreads >> How would you compare a Swing based web front end approach to the traditional JSP/JSF with HTML/Javascript one?
Marc Domenig >> Swing and ULC offer all the capabilities required for a full-fledged desktop UI while JSP/JSF and HTML/Javascript are limited by the browser. Therefore, Swing/ULC is better for applications that are used on a daily basis by experts, who need keyboard navigation, multiple windows, or other sophisticated UI functions. JSP/JSF is better for applications that are used occasionally or only once, i.e. where unconditional end-user access via browser is the most important requirement.
“A Swing/ULC web front end is cheaper to develop and maintain…”
Technically, there are significant differences: the Swing/ULC approach leads to a pervasive Java design while traditional web technology results in a mixture of Java, Javascript, HTML, JSP, JSF, XSLT, XML languages, and more. Taming this latter mixture of technology gets pretty difficult for larger applications. So there is a cost aspect as well: a Swing/ULC web front end is cheaper to develop and maintain whenever an application needs more than a truly basic UI.
IndicThreads >> ULC is an unconventional mix of Swing with Web Applications and Canoo refers to it as “Beyond Ajax”. Could you elaborate on “Beyond Ajax”?
Marc Domenig >> Swing has 8 years of development behind it. Today, its UI components leave nothing to be desired while Ajax libraries are in their infancy. For this reason alone, ULC’s functionality and reliability go way beyond that of any Ajax library.
“Swing UI components leave nothing to be desired while Ajax libraries are in their infancy…”
But there is more: both Swing and ULC have traveled down the path of standardization for 8 years: Swing is clearly an industrial standard today that is established and mature. ULC has evolved from a proprietary framework to a lean add-on library for Swing and J2EE. Ajax is at the very beginning of that road. Anyone deciding for an Ajax library today will have to write numerous UI components her-/himself, and will have to live with a rapid evolution of the library. Moreover, there is a high risk that the library will be eliminated from the market because the shakeout has only just begun. So “beyond Ajax“ also means that anyone who chooses Swing combined with ULC starts beyond the evolutionary point of Ajax.
IndicThreads >> Ajax and its framework industry is booming like never before. Do you foresee such activity in the Java RIA space?
Marc Domenig >> Ajax has the definite advantage that browsers are more ubiquitous than Java installations, which means that the market potential is bigger. In addition, Ajax is currently a hype, which leaves little room for differentiation. It is likely that Java RIAs will gain traction when the hype subsides. But there won’t be a similar enthusiasm as for Ajax, because at that point, decision makers will have a better understanding of RIA, and will be able to differentiate the pros and cons of the technology options.
“Ajax has the definite advantage that browsers are more ubiquitous than Java installations…”
IndicThreads >> There is a big pool of developers with expertise in JSP/HTML web application development and who now seem to be moving towards Ajax with JSF. How difficult is it for such developers to take up ULC?
Marc Domenig >> In fact, ULC is easier to take up than Ajax, because it simplifies matters instead of packing yet another technology on top of the medley. ULC’s programming model is purely server-side and thus similar to servlet development with plain JSP/HTML. In contrast, Ajax leads to a programming model that distributes functionality between client and server, which is a major challenge.
“ULC is easier to take up than Ajax…”
Our experience is that developers who know servlets and JSP/HTML take about two days to get productive with ULC. When the standard set of widgets – which includes the complete set of Swing components – is not sufficient, knowledge of Swing is required, because Swing is the basis to customize components. Learning Swing takes more time, but there is plenty of excellent literature on it.
IndicThreads >> Could you give us the steps involved in running a ULC RIA application?
Marc Domenig >> Typically, a ULC application is installed in a web container, either as a servlet or as a portlet in a portal server.
A user session is then started by clicking a URL in a browser, or by double-clicking an icon on the desktop. The UI will execute within the browser as an applet or a Java Web Start application on the desktop.
“UI will execute within the browser as an applet or a Java Web Start application…”
In any of these cases, Java must be available on the client, either as a browser plug-in, or on the desktop. The code of the application will be identical for all scenarios.
A further option is to run applications in stand-alone mode: ULC allows installing client and server within the same VM. This option is primarily useful for development but can also be leveraged for on-/offline scenarios.
IndicThreads >> So to run ULC, does the client need to have Java already setup? Wouldn’t it be difficult to get the right user environment outside controlled enterprise users?
Marc Domenig >> Java must be available on the client. However, the setup is much easier compared to conventional Java applications: the user needs a plug-in 1.4 or higher. Given that, any ULC application is just a click away. New applications or updates don’t require any installation. And finally, the client footprint is small and downloaded quickly.
“The client footprint is small and downloaded quickly…”
Many of our customers run their applications outside controlled environments on the web. B2B scenarios are the typical setup, where customers are prepared to do a minimal installation for their applications. An example is a Terminal Operating System that has been developed by the leading software provider for container terminals: this system is operated by the company that runs a specific shipyard, but the application is also used by the numerous parties that do business with the yard, including trucking companies, shipping lines, train operators, logistics providers, and even customs officials.
IndicThreads >> You also have adapted ULC to run on J2ME. Can you tell us more about it? Will my ULC app run on a J2ME phone without having to make any changes to the code?
Marc Domenig >> Under certain conditions, yes. ULC Mobile uses the CrEme VM, which runs on Windows CE and is therefore limited to certain devices. Furthermore, CrEme offers JDK 1.3.1 but does not support later versions, and it misses a few minor functions. One of our customers was able to migrate a major application to ULC Mobile just by recompiling. Yet, this was a test and I believe that he must adapt some of his user interface to the smaller screen size before using the PDA clients in production.
“ULC Mobile uses the CrEme VM, which runs on Windows CE…”
IndicThreads >> Which tools / IDEs can I use for ULC development? Is integration with IDEs like Netbeans or JDeveloper on the anvil?
Marc Domenig >> ULC works with any Java IDE because it’s just a library. Only the ULC Visual Editor is bound to Eclipse. Integration with Netbeans, JDeveloper or Intellij IDEA is simple, as shown by one of the numerous contributions in the ULC Community.
IndicThreads >> Is there a risk of my application getting locked into ULC APIs? Is Canoo involved in the development of any specifications / standards for RIA development?
Marc Domenig >> Minimal lock-in is maybe ULC’s biggest asset. ULC delegates every functionality it possibly can to the standard J2SE/J2EE infrastructure: it uses native Swing on the client, and standard J2EE architecture on the server. Moreover, ULC’s API is intentionally similar to Swing’s. In fact, you could say that ULC essentially transfers the Swing API to the server, bridging the gap between Swing and a server-side web architecture.
“ULC bridges the gap between Swing and a server-side web architecture…”
So our strategy regarding standards is to leverage Java to its fullest extent, avoiding a mixup with further technologies that have their own evolutionary cycle. As a result, the size of ULC’s code has been constantly shrinking to a current size of 50’000 lines, in sync with the growing functionality of J2SE and J2EE, respectively.
The specification / standards efforts for RIA are, unfortunately, not interesting for Canoo right now: they follow the HTML/DHTML approach that addresses the low end functionality space while we are focusing on pure Java with Swing, which is definitely high-end.
IndicThreads >> Could you share the highlights of Canoo’s other products for Java development, like WebTest and ULCXML?
Marc Domenig >> ULC XML is an engine that renders UIs based on descriptions edited in XML documents. As such, it offers an alternative to defining UIs with Java code, or with the ULC Visual Editor. We will officially launch this product at the end of September or beginning of October 2006.
WebTest is an Ant-based tool for automated end-user testing that has become very popular for HTML applications.
Both ULC XML and WebTest are open source products that are available free of charge.
IndicThreads >> Thanks Marc for sharing your thoughts. We wish you and Canoo the very best.
Related:
Canoo announces Rich Internet Applications (RIA) for mobile
Seven Ajax Frameworks / Toolkits to watch out for
