Savor success with Java on the front end

HTML, Swing, or XML: Choose the best front-end technology for your Java development

1 2 Page 2
Page 2 of 2

From my experience, Java Plugin is simpler to set up and is more user-friendly than Java Web Start because it requires much less involvement from administrators and users alike. Some companies are creating their own deployment tools that do a similar job, sometimes even better than Java Web Start. For example, Sitraka's DeployDirector enhances Java Web Start and promises an even easier installation.

Summing up, with Java Plugin and Java Web Start, the deployment of Swing applets is tremendously easier and safer than what it used to be, but is still more involved than just clicking on an HTML page with a bit of JavaScript. Some users may feel intimidated by going through the steps required to install the JVM on their local machines and may not get to see Swing's benefits. But if you need a dynamic GUI interface that gives a lot of flexibility to users, there is no better way than using a Swing applet.

In addition, if your entire development is done in Java, there is no mapping between HTML request data and your internal structures. RMI can offer fast round-trip network calls that can transfer native data. It can implement callback on the client to prompt users or update their screens at the server's request.

Deploying Java Swing as pure HTML

Although HTML front ends and Swing clients have their advantages and disadvantages, it is clear that the ideal solution would support both. However, because these technologies are very different in nature, only one can be typically implemented in a finished application. Even though the majority of users may prefer a fast interactive client based on Swing, downloading and installing JRE on the client's machine is not always an option. Sometimes security and firewall restrictions make it difficult to run RMI over the network. In that case, what we need is an interactive client that can run on any system, even if the only client software we can count on is the Web browser. CreamTec's WebCream -- the third deployment option -- acts as that Swing-HTML bridge.

WebCream is a Java tool that provides automated Web-enabling for GUI-based Java applications and applets. It lets you implement a GUI front end using AWT and Swing, and at the same time automatically get HTML access to the application. In a way, WebCream can be thought of as a dynamic Java-to-HTML converter that converts Java frames and dialogs to HTML on the fly. It then emulates Webpage actions as GUI events to retain the application's original logic. WebCream requires no modifications to existing forms and business logic, and does not require that you learn any new APIs. It is designed to publish existing applications and applets; it's just a matter of setting up your Web server and a property file describing the application. WebCream handles the rest. The standard edition is fully functional and available for free. WebCream does not require any installation on the client machine; in fact, it doesn't need the browser to support Java because all the browser sees is HTML.

WebCream functionality is rather unique -- to my knowledge, no one else offers the same solution. However, a few products serve the same purpose using a different approach to Web-enabling applications that were not built for the Web. Windows 2000 has a built-in Terminal Server service that lets users access their servers remotely as if they are logged in locally. Terminal Server, just like Citrix Systems' MetaFrame, sends a video stream to the remote terminal and emulates user actions for applications running on the server. It works very well on relatively fast networks but can be jerky if you have network latency. It is also known to have problems with Java applications because they don't use native drawing and scrolling routines. Terminal Server is also not very scalable because each user is essentially given an individual copy of the application. The application delivered by WebCream is different in form from the one that runs on the local machine, but it provides a much better experience because the server is only contacted when the user submits a page. All users served by WebCream-enabled applications can share a JVM, which greatly reduces resource consumption.

To illustrate how WebCream works, the images below show how a sample GUI application looks in HTML when WebCream is used. On the left the snapshots show a running GUI application (the source). On the right, WebCream manages the same application, with the windows being represented by pages in the browser.

Figure 1. Sample GUI application
Figure 2. Sample GUI used with WebCream

While this Swing-HTML bridge may not work for all clients, WebCream can certainly add value to Swing-based front ends by allowing access to the front end via HTML. Some 95 percent of applications typically convert to HTML seamlessly, and for the remaining 5 percent you may have to change how the data is presented or handled. For complete information on WebCream visit Resources.

Emerging choice: XML/XSLT-based client

Assuming that you have a basic understanding of XML, I will focus on its applications in front-end development. The major difference that is associated with XML in user interface development is the clear separation of content from presentation. In simple terms, data is kept as XML documents that make no assumptions about how the data is used and displayed. Each presentation type -- HTML, WML, XHTML, and others -- is achieved by applying a "stylesheet" (XSLT) that determines how the data is formatted and laid out on the page. This approach has obvious advantages by keeping the layers relatively independent of one another, letting each layer perform its own task.

While XML certainly provides you with a neat model of publishing data and generating different presentation models, it is not a panacea. XML deserves praise for letting developers stick to data, while designers and artists work on the presentation. The application generates XML data files that are either kept in memory or written to a disk. To obtain a specific type of presentation, such as HTML for example, the content is transformed using the appropriate XSLT stylesheet. The stylesheet is applied to the XML document to output an HTML document. Stylesheets are like templates that determine what data from the document goes where on the page. They can also transform data, execute conditional statements and loops to manipulate the data, and make decisions. So things can get quite complex.

The beauty is that if you need to provide access to the same application from a mobile phone, all you have to do is create a new WML stylesheet. Theoretically, no other parts of the application will have to change, which makes server-side programming very efficient. Implementing a front end using XML can make such tasks as branding, personalization, and customization very easy because the data to be displayed and the code that handles it doesn't have to be changed. Team members can work independently on various parts of the application, which speeds up development.

However, I have stumbled across a number of obstacles that have actually prevented me from going forward with an XML-based client for an upcoming release. Two major drawbacks are the lack of tools that help with XML generation and stylesheets development, and processing speed. The first one hurts especially those souls who are used to designing their HTML pages with visual HTML designing tools like DreamWeaver and FrontPage. Personally, I still like browsing through and, at times, editing the code generated by DreamWeaver. (I stay away from FrontPage.) But I certainly see no fun in writing HTML from scratch in a text editor; after all, this is the 21st century. Now, let me show you what is a very simple XSLT stylesheet for transforming a small XML document to HTML:

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="">
<xsl:template match="page">
      <title><xsl:value-of select="title"/></title>
<xsl:template match="title">

Given the proper XSL stylesheet, the code above would generate an HTML page that looks like this:

  <title>My first page</title>
    <h1>Hello, world</h1>

As you can see, while not terribly sophisticated, the source for this page looks quite different from an HTML page you normally might see. Unfortunately, the only way to work with it is by editing it manually, running it through a tool that will produce an HTML document, and then opening that document in the browser. That is a lot of steps if all you need to do is change the font size for a better look.

The second problem is that it takes a lot of time to perform all the steps at runtime. If you are using any storage other than XML, you will start with the generation of XML documents. Then the appropriate stylesheet is applied to do the transformations before you can finally generate the output HTML page. Compare this with optimized writing into a memory buffer inside a servlet or a JSP, and you get the idea. Speed and simplicity is not the virtue of XML-based front ends given today's technologies.

To summarize, use XML when you need to dynamically generate the presentation using different layouts and forms. If your presentation format may change frequently or has to be very flexible, it may be easier to let the presentation designer create a new stylesheet; remember that the designer only needs to know XML and XSLT.

Another good use of an XML-based UI is when your data comes to you in XML as opposed to native Java types and objects or a relational database. XML is an emerging technology that will most likely have a solid place in the future of the Web. However, today it is actually a lot easier to develop HTML using JSP for presentation, especially if HTML is your only front end. Using well-known design patterns such as JavaBeans and tag libraries for JSPs provides a very clean separation between the content and presentation, which is almost as good as XML/XSLT. And it will work a lot faster. With the advent of tools that automate XML/XSLT editing, these technologies will become a lot friendlier and easier to use.


Each front-end technology has its benefits and disadvantages when it comes to the interface to your Java applications. None of them is superior to others in all aspects. For each specific application, you must perform an evaluation of these technologies with analysis of requirements and user expectations. Here are the basic rules of thumb:


  • For relatively static content enriched by graphics and professional art
  • If your interface needs to work for all user types running different software
  • If users access your application from slow networks
  • If you want to quickly build an unsophisticated application

Use Java Swing:

  • For highly interactive GUIs with built-in, interface-related logic
  • To reduce network traffic and provide immediate response when possible
  • If users have high expectations for the quality and functionality of the interface
  • If UI functionality is more important than aesthetics


  • When a number of different and rapidly changing forms of presentation need to be supported
  • When the data is natively stored or obtained in XML
  • If you need to support branding and sophisticated personalization
  • If you are planning to provide alternative methods of UI, such as wireless access
Alex Kalinovsky has been in the IT industry for more than nine years, with experience that ranges from developing with C and C++ on Windows, to Java on Unix. Since 1997, Alex has worked solely with Java and is proud to be one of its original evangelists and gurus. He has worked as an architect and tech lead on various enterprise-level projects involving EJB, CORBA, Servlets/JSP, XML, Swing, and others. He has taught more than 15 different classes on enterprise Java technologies and worked as a mentor for many teams. Alex has written for various publications, including Information Week and the Washington Post.

Learn more about this topic

1 2 Page 2
Page 2 of 2