Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Are applets making a comeback?

Good old applets -- do they deserve a place in your RIA toolkit today?

  • Print
  • Feedback

Page 2 of 7

JRE deployment

Today, when Java developers write Web pages that incorporate applets, we have to hope that users will be able to run them as they're intended; that they'll have the most current version of the JRE installed, or at least the version for which that applet was written. This is a source of frustration for many of us because no matter how well-written a given applet might be, it will not run well on an outdated JRE. Furthermore, users have to deal with the annoying notification that the Java technology embedded in a given page will not run properly due to that same outdated JRE. Few users will take the time to manually download and install something as amorphous as a "Java Runtime Environment" before viewing a Web page; most will just quickly navigate to some other page.

Java cold start

Startup performance and Java Virtual Machine reliability are two further challenges to crafting a satisfying user experience based on applets. Users often face a lengthy delay the first time an applet is encountered because the browser must load and start the JVM -- this issue is known as a cold start. Worse, browsers have been known to freeze due to a virtual machine crash -- hardly a way to make a good impression on a visitor to your Web application or site!

Tidy poor clients

In an age when the mantra for desktop and Web developers is "filthy rich clients" Java's client-side technologies are simply lagging. For just a few examples, most developers favor a simple drag-and-drop UI-composition model, but Swing doesn't have it. Swing also lacks support for animated transitions, an important aspect of many rich user interfaces. And finally, the Java Media Framework (JMF) was last updated in 2004. It really isn't up to the challenge of today's rich media demands.

I conclude that JRE deployment, startup performance, JVM reliability, and UI-related problems are all external factors that plague applet-based development. When I queried the developers in my "applet think tank" on this topic, some of them shared my conclusions, and also expanded upon them.

What's wrong with applets?

Q: What's wrong with applets -- why are so many Java developers migrating to technologies such as Flex, Silverlight, and Ajax?

Danny Coward: I think some developers have turned to Ajax because its deployment model was easy and because JavaScript, in some flavor or other, is in every browser. I think Flash is riding the wave of media rich applications and the Flash runtime is widely deployed. I think as [Sun] added features to Java SE, we were slow to realize that we were getting behind in being the best development model and runtime for rich client applications.

So I think our JRE got heavy, and became perceived as this big thing that was slower to start than it need be for consumers using the apps, and I think our development model for GUIs, while rich and highly capable, became better tuned for more traditional desktop applications in the enterprise.

Romain Guy: Many programmers have pointed out many, many reasons [for the demise of applets] over the years. While it is true that deployment issues and loading times didn't help applets, I doubt it was the real reason for their demise. The best asset that Flex and Silverlight have is simply a great designing tool. It is very easy for non-programmers to pick up such a tool and get started on something that looks and feels nice. Their programming model is also easy enough to allow non-developers to learn it and use it efficiently enough. Competing on the RIA market today is, to me, not viable without a good tooling solution.

Chet Haase: I think deployment continues to be the single-biggest issue with applets in the real world. Although Java now comes bundled with a large percentage of new machines, there are still some users without the runtime, or without the right version for a particular application, so they need to install Java. Given the size of Java, the installation or update process is not insignificant, and some users may choose not to go through that process.

This, then, feeds back to potential applet developers and makes them decide either to use alternate technologies without this deployment issue, or to use earlier Java APIs (that were available in version 1.1) that may serve a larger base of users that have some flavor of Java installed (even the Microsoft VM). If they go the route of using applets that target older versions of Java, then they don't get the benefit of years of progress on the Java APIs, and their users don't get the benefit from the code being easier/faster to write, enabling richer content, and so on.

Or they give up and choose other technologies entirely. So the applet market tends to be stale and historical, at least in the consumer space where deployment cannot be mandated and managed as it is inside company networks.

Cay Horstmann: #1. Java on the end-user machine. It's a mess.
a) Which version of Java?
b) Is it integrated with the browser, both for applets and Web Start?
c) Does it actually work? Is there a conflicting JVM (Microsoft on Windows, Classpath on Linux)? Are there bits and pieces of an earlier installation that cause mysterious interference? Is the browser linkage broken? There is a good chance that Java is not properly installed for a given end-user. Unless you enjoy doing tech support for them, that's a huge disincentive.

#2. Programming model. Java has no API for flashy transitions or rich media. If you want a consumer look, you can hire either very bright Java programmers or just code it in Flash.

  • Print
  • Feedback

Resources

More from JavaWorld