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.
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
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
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.
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://22.214.171.124/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