Savor success with Java on the front end
HTML, Swing, or XML: Choose the best front-end technology for your Java development
Summary
Java architects and managers face the challenge of choosing among Swing-based, HTML-based, and XML-based front ends for their applications. In this article, Alex Kalinovsky shares his experiences with these three technologies, and provides criteria and tips for choosing among them in your Java development. Finally, you‘ll learn an innovative approach that bridges Java Swing and HTML with minimal effort. (3,900 words) By Alex Kalinovsky

re 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:






Sorry, looks like I bumped into another browser that doesn‘t support Java applets


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