Savor success with Java on the front end

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

Are you tired of the hype and publicity forced by sales and marketing departments to promote their technologies? Java has enjoyed a flow of positive and negative press, quite often giving contradictory information and creating chaos in public opinion. In this article, I'll give a realistic assessment of the state of Java, and will try to answer the question, "What options do we have today when it comes to Java on the front end?"

Obviously, Java entrenched itself on the server side where it has clear advantages over any other existing technology. However, just about any application has some form of user interface and front-end presentation. Many of us have been so bombarded with bad press on client-side Java (remember how many times we've heard about "nails in the coffin of Java"?) that advising anything other than an HTML-based front end would be like digging your own grave.

Reality is that there are more choices than a plain old HTML client. I'll cover three major solutions for developing the user interface in Java-based applications. I'll start with the pros and cons of using HTML with JSPs and servlets. Second, which might sound surprising, I will revive the idea of one of Java's original promises: interactive Web via GUI applets. Finally, I'll move into XML and the myriad other X-rated technologies that sprang up around this new language. Now let's get down to what you really want to know -- the tech facts.

HTML client with JSP/servlets

By now, most of you have written some sort of servlet, created JSPs, and faced the pros and cons of the HTML-based user interface. The strongest argument for choosing HTML is its wide acceptance on any platform. (Wouldn't it be great to be able to say that about browser support of Java?) Basic HTML is well standardized, and without getting too fancy, you are guaranteed to have a positive experience.

Given the simplicity of HTTP/HTTPS protocols, you are also guaranteed to enjoy the predictability of programming for various network configurations and firewalls. But as with everything else on this planet, that comes at a price. The trade-off with HTML is the lack of user interaction and the necessity of making network trips to the server for every response to a user action.

Sure, JavaScript, which is a beast in its own right, exists. But, as a programmer, have you ever tried a more mentally challenging feat than enforcing mandatory fields and creating simple prompts, and making them work the same in all browsers? Simplicity is not always a good thing. Simply put, JavaScript is a great language for adding uncomplicated interactive logic to otherwise static HTML, but it is not one for developing sophisticated user interfaces that will impress the user with self-intelligence.

Unless you have digitized yourself and live in cyberspace, or own a T-1 line at home, you have experienced the frustration of waiting for a Webpage to load or for the server to get you through a sequence of useless pages. Although thin clients offer ways for great presentation of many noninteractive user interfaces, traditional fat clients certainly surpass them in intelligence. For example, online brokers give application clients to active traders that work much better than their HTML clients. Email clients, like Netscape Communicator and MS Outlook, are much more user friendly than Web-based email portals.

Using Java to develop an HTML front end is a great choice because, just as HTML provides a cross-platform way to deliver and lay out the content, Java servlets and JSPs allow programmers to write server-side logic that can be executed on any operating system in virtually any environment. Given the vastness of Java APIs and broad support by vendors of Web servers and application servers, Java is the ideal choice for building scalable Websites.

To summarize, an HTML front end using servlets and JSPs is a great way to develop static content (and folks, please use a professional artist to design those pages). However, this thin client doesn't score very high when you need quick responses to the users' actions and sophisticated logic that manipulates data quickly.

Swing-based GUI client

How many of you would even dare to use a Java applet as your client today? You are certainly safer using an HTML-based UI, but is that always the best option?

Telecorp PCS, a subsidiary of AT&T, had to create an application that would allow its stores and kiosks to collect information from customers wishing to purchase cell phones, run credit checks on them, and then activate phones on the spot. Besides numerous validations of user input, the client application was required to produce interactive reports with sorting, filtering, and other standard table features. On top of that, the client was supposed to be able to display a notification when a new cell phone had been activated by way of an instant message.

Can you picture implementing this in HTML? It's possible, but it would be a rather cumbersome and slow app that would need to constantly use the network to get anything done. The development team ventured to try Java for what it was originally intended -- interactive applets. Result? Total success! The applet was developed using Swing and deployed on the Web using Java Plugin. With Swing UI classes, it was easy to provide on-the-spot validations for invalid inputs, buttons that enable/disable themselves if the user can/cannot proceed, tables that are sorted by simply clicking on the column header, and the instant message is an RMI callback that pops a dialog. And users loved it.

I'm sure many of you have tried applets in your early days of Java. Most of us wasted hours fighting with the differences among browsers, applet download time, performance, and all kinds of things that marred the picture. The criticism of client-side Java was mostly objective. But, there is a big but: things have changed. Sun Microsystems has spent a lot of time improving its code and our lives. I will show you why a Swing-based UI is worth your consideration.

Swing and its deployment models

I don't need to praise Swing's internal architecture and the amount of thought put into designing the classes and interfaces, and implementing the design patterns. Swing is probably the cleanest implementation of a windowing system that I have seen. It has well-defined relationships between containers, components, and UI elements. Swing's architecture is based on the Model-View-Controller (MVC) design pattern, which separates data from presentation and the manipulation of that data.

Most Swing models are shared by various UI elements; for example, JTable uses the same selection model as JList and JTree. This makes it easier to learn and use Swing. Patterns such as Command, Observable, and Listener provide flexibility and good object-oriented design. Probably Swing's only significant architectural shortcoming is that all events are delivered in the same EventDispatch thread, making the entire GUI client single-threaded. However, you can easily overcome that by using separate threads to respond to user commands instead of performing these actions on the EventDispatchThread.

Every JDK release improves Java and Swing. JDK 1.3's most important enhancements related to Swing are performance, memory consumption, and an input validation framework. The performance and memory improvements are dramatic. Since my company migrated its client from JDK 1.2.2 to 1.3, we've seen the memory usage drop at least 30 percent; some applications have enjoyed even greater savings. Because Swing's internal initialization was optimized, our client comes up a lot faster and is more responsive. In short, the biggest speed impediment was loading a large number of classes automatically created by anonymous interface implementations. The solution was to have one class that relies on a reflection mechanism create the right implementation proxies. Another major change is that now the default JVM is HotSpot Client VM, which is optimized for GUI drawing and client-side execution. You can find out the default JVM by running java -version at the command prompt.

An input validation framework allows you to easily program mandatory fields or entry validation. Previously, to ensure that a user entered a value before proceeding to the next field, you had to add a listener to the component, and every time that component lost focus you would validate and possibly restore the focus. This was rather messy and tedious. With the new InputVerifier class, you can achieve the same effect by creating the instance of the InputVerifier subclass and setting it to the JComponent that needs validating. The component will automatically call the verify() method before allowing the focus to be transferred.

Swing's perpetual problems from the beginning were speed and incompatibilities at deployment time. Short answer: today a dramatic improvement solves those problems and makes Java clients a viable option again. CPU speed practically doubled over the last couple of years. With JDK 1.3, Swing applications have started working much faster, consuming a lot less memory. This leaves us with the last obstacle -- deployment -- where we have three options.

Java Plugin

One of the best things that happened to browser-based Java is Sun's Java Plugin. The simple modification of your HTML page removes the dependency on the browser JVM and allows you to run your applet in Sun's standard JVM. Once the JRE is installed, your applet gets downloaded and cached, and then opening an HTML page with your applet is instantaneous, since everything is loaded from the client's disk. To illustrate how that works, let's take a look at the old-style deployment of applets and see how the HTML page is transformed to use the plug-in. Let's say you have mastered your knowledge of HTML and Java applets and produced a page that looks like this:

<HTML>
<HEAD>
<TITLE>My traditional applet page</TITLE>
</HEAD>
<BODY>
<APPLET CODE=HelloWorld.class ARCHIVE=HelloWorld.jar>
Sorry, looks like I bumped into another browser that doesn't support Java applets
</APPLET>
</BODY>

The trouble with this approach is that it relies on the browser JVM to load and execute the HelloWorld class. With many browsers on the market now, the disparity in how they implement Java (if they do at all!) turns applet deployment into a nightmare. So what is an easy way out? You must ensure that you always execute in the JVM with which you have tested. Instead of asking the browser to run Java, we will ask the browser to install and run the JVM that will in turn run our applet. For Internet Explorer (IE), you use the <OBJECT> tag to accomplish this; for other browsers, the tag can be different, such as the <EMBED> tag for Netscape Navigator. Let's take a look at our modified page:

<HTML>
<HEAD>
<TITLE>My new applet page</TITLE>
</HEAD>
<BODY>
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" 
        width=100% height=100
        codebase="./j2re-1_3_0_02-win.exe#Version=1,3,0,2">
   <param name="code" value="HelloWorld.class">
   <param name="archive" value="HelloWorld.jar">
   <param name="cache_archive" value="HelloWorld.jar">
   <param name="cache_option" value="Plugin">
</OBJECT>
</BODY>

The above page will tell IE to check whether or not the object with the given class ID is already installed. If it isn't, it will download the JVM from the given URL and install it (which actually registers the plug-in with IE). Then it will execute the plug-in, which in turn, will load and display the applet. You can see how it works in one of Sun's examples at http://192.9.48.9/products/plugin/1.3/demos/applets/GraphLayout/example1.html. Further details on Java Plugin can be found on Sun's Website.

The great thing about the plug-in is that it absorbs the burden of supporting all browsers on all platforms, plus you are given a guaranteed execution environment. The plug-in needs to be installed only once and then it caches all applets, making the return visit to your page a pleasure. The biggest disadvantage of this approach is that users are required to download a 5MB plug-in before running your applet, which can be very painful on slow connections. In fact, if your applet is a small 5KB clock at the top of the page, then downloading a 5MB plug-in to display it can be overkill.

Java Web Start

Another emerging way of deploying Java applications is by using Sun's Java Web Start. It is similar in nature to Java Plugin, but differs mostly in the first step. Java Web Start requires manual installation on each desktop machine, which is more tedious than the browser's automatic installation of the plug-in. Java Web Start comes with the JRE and is rather easy to set up. Once it is set up, the applications that rely on Web Start can be downloaded and installed. Just as with a plug-in, the application is jarred and published on the Web. An HTML page lets the user launch the downloaded application to the user machine if it is not yet available. Downloaded applications are cached and can be launched independently through Java Web Start Application Manager, which looks very much like the Program Manager of Windows 3.1. For more information on this technology visit

Resources

.

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="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="page">
  <html>
    <head>
      <title><xsl:value-of select="title"/></title>
    </head>
    <body>
      <xsl:apply-templates/>
    </body>
  </html>
</xsl:template>
<xsl:template match="title">
  <h1><xsl:apply-templates/></h1>
</xsl:template>
</xsl:stylesheet>

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

<html>
  <head>
  <title>My first page</title>
  </head>
  <body>
    <h1>Hello, world</h1>
  </body>
</html>

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.

Conclusion

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:

Use HTML/JSP:

  • 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

Use XML/XSLT

  • 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