Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Java Web Start to the rescue

Find out how Java Web Start aids client-side deployment

By Raghavan N. Srinivas, JavaWorld.com, 07/06/01

Java applets fuelled Java's initial growth. The ability to download code over the network and run it on a variety of desktops offering a rich user interaction proved quite compelling. However, Java's Write Once, Run Anywhere (WORA) promise soon became strained as browsers began to bloat and several incompatibilities emerged that were caused by the Java language itself. In the meantime, Java proved a disruptive technology yet again by making a mark on the server side.

Recently, Java began making a comeback on the client side with technologies such as Java Plug-in and, more recently, Java Web Start. Also, the Java 2 Platform, Enterprise Edition (J2EE) incorporates technologies such as JavaServer Pages (JSP) that support desktops and a multitude of client devices by serving up HTML, XML, and so on.

Using markup languages to generate user interfaces proves advantageous due to those languages' ubiquity and light weight. However, a markup-language-based UI is fairly limited. Java Web Start overcomes this main limitation while preserving some of a markup-language UI's main benefits, such as using a network URL as a launching point, updating client applications without intervention, and so on. Using Java Web Start, it's possible to design desktop Web clients that provide a rich user experience decoupled from a browser.

In this article, I will primarily look at Java Web Start. However, to begin I will provide some background on the motivation behind the technology, and compare and contrast different approaches for designing Web clients using various available technologies.

At the trail's root: Java applets

"An applet is a small program that is intended not to be run on its own, but rather to be embedded inside another application" -- so says the Applet Javadoc. Browsers represent the typical application in which an applet is embedded. Coupled with the rapid growth and ubiquitous availability of browsers, applets provided a nice delivery vehicle for distributing applications to thousands, even millions of desktop clients with the click of a mouse.

Although applets offer several advantages -- a rich user interaction, for example -- they are restricted by the environment in which they execute: the browser. Another issue is that applets are embedded in HTML. HTML downloads quickly because it focuses solely on presentation. Applets are much more general, and therefore slower to render. Mixing the two on the same page results in an impedance mismatch.

Applet developers must also support different versions of Java in various browsers, making it difficult to meet the WORA paradigm. Further, the slow download time can make invoking a Java applet a jarring experience for the user, a problem that does not improve with subsequent uses.

Finally, from a security viewpoint, applets are restricted by the sandbox environment, which provides a powerful defense against rogue applications. Although this model is simple to understand, it is fairly inflexible in that it does not support actions, like local disk access, that are reasonable requirements even for network-downloadable code, provided that the actions can be accomplished securely.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.