Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

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?

By Jeff Friesen, JavaWorld.com, 05/05/08

Page 3 of 7

Ted Neward: A couple of things combined to make applets unpopular: First, the difficulties of writing AWT (and later Swing) code by hand, compared to the drag-and-drop model of UI composition favored by other tools, though I think this wasn't so much a criticism of applets as GUIs-in-Java in general; second, the relatively limited functionality of the early AWT releases meant that Java developers could produce GUIs that were basic block-and-line diagrams compared to the sexier (though limited compared to today) three-dimensional effects that were appearing on the individual operating systems, most notably Windows 95; third and quite possibly most of all, for a variety of reasons, browser support for Java stalled, leaving only JDK 1.1 in place by default. This meant that not only would users of your applet-based systems be limited to UIs that were built on top of AWT 1.1 (unless you forced your applet users to sit through the sizable Swing .jar download), it also meant that many of JDK 1.2's notable enhancements were also lost to you, such as Java's new collection classes and thread enhancements. Java developers weren't ready to give that up, yet trying to make the Java Plug-In (once it came out) just struck many IT shops as too much work -- the point of a browser-based application is zero deployment cost, and having to push (or trick clients into pulling) the JDK onto the target machine seemed counterproductive.

These elements by themselves weren't enough to drive developers to Flex/Silverlight/Ajax -- those tools hadn't really been developed yet -- but it did drive developers to prefer HTML-based UIs over "richer" UIs, which were easier to control and deploy. That in turn led to the general realization a few years later that HTML's expressiveness as a UI is highly limiting, creating pressure to find something "snazzier" to dress up our applications in, and thus was born the drive to pick something -- such as DHTML, Flash, or even PDF. When Flex came, making it easier for Java developers to connect to Flash-based front-ends, that made for a compelling story. Silverlight has yet to really prove itself in the market, but already people are exploring how to connect Silverlight front-ends against Java back-ends, with some mixed results. (No doubt Microsoft will push that envelope harder as the interoperability story evolves.)

Jim Weaver: Deployment of the Java Virtual Machine (JVM) has been the biggest issue. Back in 1995 when the JVM was introduced, I thought that it would quickly become ubiquitous on operating systems and in browsers. Then the browser wars, etc., happened, and 12 years later we're finally getting to the point where the JVM will be nearly ubiquitous soon.

John Zukowski: My clients have typically been in the corporate world, not needing public deployment of solutions/applications. For that environment, they've usually had client-side, Swing-based applications, sometimes deployed by Webstart/JNLP off a corporate server to keep the latest version on the user's machine. They don't want something where you are tied to running within a browser. I have yet to run into anyone interested in using Silverlight. With at least Flex and Ajax, they work fine when Web-based solutions are needed. With things like Adobe AIR, that is more like the client-based, browser-disconnected approach I typically run across. For all of these worlds, applets are typically avoided for both perception and what I would call trend-following reasons.

Since the early days of the Java platform, applets were always thought to be not worth the hassle of creating. There were issues with dealing with browser differences, including from a security perspective, packaging differences (CAB vs. JAR), and just outright incompatibilities, runtime versions were not always the latest on user machines, and you couldn't assume the world had broadband to force them to get the latest. All of those issues have been addressed with newer releases of the Java runtime environment / Java Plug-in. Though, broadband everywhere can get a little questionable, depending upon your user base. Even startup time has been addressed, though sometimes you wonder if it is just faster hardware that doesn't just help perception quite a bit.

As far as the trend-following comment goes, it seems good developer talent is in more limited supply these days. With those that are available, it is easier to sell a solution using a technology that someone just finished using than to learn something new. With companies, this helps them retain the good developers they already have, as otherwise, they may learn the new technologies elsewhere.

Java SE 6u10: The client-side panacea?

Needless to say, none of the problems discussed so far are new to applets, and most of them are addressed in Sun's most prominent client-side initiative, Java SE 6 update 10. If the problem is applet execution -- with the symptoms being JRE deployment, startup performance, and JVM reliability -- then Java SE 6u10 offers the following solutions:

• Java Deployment Toolkit: Simplifies the task of deploying applets and applications to a variety of clients. It consists of a JavaScript file (named deployJava.js) and a browser plug-in (currently for Windows only) that make it possible to automatically install a JRE.
• Java Kernel: Lets first-time Java users run applets and applications faster by downloading only that part of the JRE needed to immediately run the applet/application, and subsequently downloading the rest of the JRE in the background.

• New download engine and patching algorithm

  Beginning with Java SE 6 Update 11, a new download engine will work with 6u10's new patch-in-place strategy (future JRE updates will be applied in the existing JRE directory so that only changed files need to be downloaded) to reduce the size of future updates. To avoid interfering with a user's Internet usage, this engine will monitor that usage and throttle back its own bandwidth. Furthermore, the engine will automatically resume interrupted downloads.

• Java Quick Starter: Pre-fetches portions of the JRE into a memory cache, greatly reducing the average Java platform cold startup time (the time to launch a Java applet or application for the first time following a computer reboot).
• New Java Plug-in: Improves reliability by running applets in OS processes separate from the browser. If an applet fails, the browser is not affected. Other improvements include each applet being able to increase its heap size and improved Java/JavaScript communication.

On the face of it, these technologies should improve the user experience with applets, thus making them a viable alternative for Java-based rich client development. Responses from the applet think tank were more varied.