Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters

Email Address:

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.

1 | 2 | 3 | 4 | 5 |  Next >
Resources