Are applets making a comeback?

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

Once the darling of the Internet, applets have fallen on hard times, largely ignored in favor of newer technologies such as Ajax, Flex/Flash, and Silverlight. But Sun Microsystems is pushing hard for renewal on the client side, and some say applets are part of that vision, along with Java SE 6 update 10 and JavaFX Script. Is it too late for applets, or can they make a comeback? In this JavaWorld feature, Jeff Friesen poses that question to leading thinkers and doers in the Java developer community, as well as presenting his own conclusions. Also see "The new applet experience," a short experiment in developing a "rich Internet applet" using JavaFX Script and key technologies found in Java SE 6u10.

Java applets generated considerable excitement when they were first introduced, but factors have conspired, since then, to cool developer and end-user enthusiasm for them. These days applets have largely been forgotten by Java developers working in the RIA (rich Internet application) space. When we think of writing browser-based, consumer-friendly applications, most of us think of Ajax, Flex/Flash, or Silverlight. None other than Bruce Eckel has pronounced applets dead for RIAs -- and he's not the only one who has said it.

Talk to Sun engineers working on Sun's consumer and client-side initiatives, though, and you get another story. They'll tell you that news of the demise of applets is premature. Consumer and client-side technologies JavaFX Script, Java Media Components (JMC), and Java SE 6 update 10 (formerly Consumer JRE) were all in the spotlight last year at JavaOne 2007, and they feature heavily in this year's lineup, too. Reports back from some developers (including this one) who have played with Java SE 6u10 and JavaFX Script are good. Add to that the possibility that JMC could be included in Java SE 7, and the future of applets begins to look brighter.

The question for many of us is whether it's just too late for applets. Java SE 6u10 unfurls a small army of technologies whose sole purpose is to improve the Java end-user experience -- including the Java Deployment Toolkit , Java Quick Starter, Java Plug-in, and the Java Kernel. JavaFX Script and JMC add further muscle by providing concrete -- and even exciting -- alternatives to Flex/Flash and Silverlight. The problem is that most Java developers have already given up on Java on the client side, and bought into the promise of slicker technologies that caught that wave when it was coming in, rather than chasing it, as Sun seems to be doing today.

To investigate the potential of Java on the client side, and of an applet comeback, I posed a series of questions to some of the most respected thinkers in the Java developer community. Some have professional stake in the future of Java on the client (Danny Coward) while at least one other could be said to have migrated to the Adobe dark side (Chet Haase). Striking a balance between these poles are Java technology educators Cay Horstmann and John Zukowski, platform agnosticists Ted Neward and Romain Guy, and Jim Weaver, whose experiments with JavaFX Script have aided my own learning.

I thank these gentlemen for taking the time to answer my questions.

Bad applets never fall far from the tree

JRE deployment in controlled environments
Although JRE deployment is a major issue facing the average user, it's less of an issue for large companies with managed networks.

The truth about applets is that they are blamed for many problems for which they are not at fault. Perhaps the most important of these is JRE deployment -- getting the correct version of the Java runtime environment installed (and in a timely fashion) onto a user's machine so that an applet is able to run at its best. Poor performance is another problem, first due to the so-called "Java cold start" and second due to the unreliability of the JVM itself. Finally, the Java platform itself (and not just applets) has been a poor vehicle for developing rich, interactive user interfaces.

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.

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.

Testing the panacea theory

Q.What are your impressions of the Consumer JRE/Java SE 6u10? Is it enough to repair the existing problems with Java deployment and applet startup?

Danny Coward: I think we've nailed both of those issues in this release, but since Java SE 6 update 10 is currently in beta, I think developers will be the ones to answer that question for themselves by trying it out This release makes a massive leap forward in addressing the speed of applet startup -- especially from "cold" (when the JVM is not already running), by loading the JRE files into the disk cache we're on a par with warm startup. The Java Kernel project has brought the initial download down to just under 4MB which is way smaller than the current beta of the Adobe AIR download.

Romain Guy: Java SE 6u10 is a great step forward. The applets experience is a lot better than it used to be. I doubt this will be enough to make applets gain momentum again though. As I said earlier, it's more about the tools than the technology itself. It will still be great for companies that already use applets based solutions or even for the games market, still quite strong as far as applets are concerned. But again, I don't see these improvements help reverse the trend of applets going away.

Chet Haase: Update 10 is definitely making great strides toward fixing some of the pain points in Java deployment over the years. Between Quickstarter, Java Kernel, and the new plugin architecture, these changes should help address some of the biggest holdups to applet adoption.

There are still some fundamental constraints with the Java platform that cannot be solved with these changes, however. For example, Java Kernel can make the initial launch experience faster than it currently is because it lessens the amounts of bits being downloaded, installed, and loaded. But there's still a lot of data that has to come down simply because Java is a large platform with a lot of interdependencies in the Java APIs. I believe that Java Kernel is probably the best that can be done with the heavy and important constraint that Java continues to be a single platform that can be depended on for various capabilities in a backward-compatible manner; you can't simply start whacking stuff out willy-nilly and expect to keep the Java developer community happy when their favorite APIs disappear.

Java Kernel will certainly speed things up, but will it be enough to overcome some of the objections to slow install in general? Time and experience will tell. It's not clear whether these changes will be enough to hoist applets into the forefront of Web applications again, but it's certainly worth having these problems addressed for any developers and users that want to consider using applet technology (or any other desktop Java technology that also benefits from these changes).

Cay Horstmann: Decreasing start-up time is great. Doing this kind of work is Sun's strength.

The installation needs a lot more work. I installed the update on Windows and Linux and it failed on both. On Windows, re-running the installer solved the problem. On Linux, I had to fix the browser linkage by hand. Granted, it was a beta, but you'd think after ten years these guys could build an installer that works.

The Deployment Toolkit is a step in the right direction. Ask me in a year whether Sun let it wither on the vine, or whether they are actively maintaining it.

Jim Weaver: I really like Java SE 6 update 10 ... as it addresses the issues that made applets impractical in the past [... T]he incremental Java kernel installer loads just enough of the Java kernel to run a simple "Hello World" style program, and incrementally updates the kernel as needed. This avoids the long waiting time to install the JRE, the net result being that the applet starts up as soon as enough of the kernel has been downloaded to support it.

The next-generation Java plug-in addresses reliability, configurability (if that's a word), and communication with the environment.

JNLP support means that the user can click a link in a browser and the Java/JavaFX application is invoked in a separate window, external to the browser (but within the Java plug-in). By the way, I think that RIA (rich Internet applications) aren't just for browsers, and that developers and users will become increasingly willing to create and use RIAs that are external to the browser.

John Zukowski: I like what I've seen so far. It appears that Sun is listening and trying to address perceived problems with deploying client-side applications meant to be delivered through the browser. Will it cause more people to write applets? I doubt it. While there doesn't appear to be anything wrong with the new changes, certainly making things better, I can't see them as fixing perception on why people do not write applets.

Nimbus and hardware acceleration
In addition to focusing on JRE deployment, startup performance, JVM reliability, and other problems related to applet execution, Java SE 6 update10 focuses on making Swing-based UIs more appealing. It does this by offering Nimbus, a modern cross-platform Swing look and feel that improves on Swing's Ocean and Metal predecessors. Update 10 also offers a hardware-accelerated graphics pipeline based on Microsoft's Direct3D 9 API, which is intended to improve the rendering performance of Swing applications that rely on translucency, gradients, arbitrary transformations, and so on.

Wooing client developers to applets with JavaFX Script

JavaFX Script is another technology that factors heavily in Sun's client-side effort. It could also play a role in an applet comeback by making applets easier to write. The language is meant to simplify the development of Swing-based UIs by offering features such as a declarative syntax, data binding with incremental evaluation, and keyframe animation. I've written more about my own experience with JavaFX Script in the companion to this article: "The new applet experience," so here I'll just offer my question and the wide range of responses.

Q.Could JavaFX Script woo UI designers away from Ajax, Flex's ActionScript, and Silverlight's XAML?

Danny Coward: I think the language is way ahead of JavaScript or dialects of it like ActionScript in terms of what UI designers and developers need. Look, JavaScript is really popular for Web programming and has some awesome features like dynamic typing, but it wasn't designed with today's rich client applications in mind. If it was, it wouldn't be plagued by all the differing implementations in the browers for one. In fact, one of the cool things about NetBeans 6.1 is that with its new JavaScript editing support, it can detail which methods and features are available in which browser. It's a reality that the NetBeans team have addressed really well, but as a rich client developer, you just shouldn't have to worry about that matrix of features and when or on which browser you are or aren't allowed to use them in the first place.

JavaFX Script was created by Chris Oliver in reaction to his own difficulty creating lightweight, highly visual GUI apps on the Java platform. So from the ground up it was designed with those apps in mind. Animation support is part of the language [...] as are other features like data binding -- making it super easy to attach data to a visual element in an application, and properties -- making it very concise to create new visual objects.

And because JavaFX is built in Java, this is all running on our tried and tested JVM, its facile to use existing Java components or libraries from JavaFX Script. And with the new plugin architecture in Java SE 6 update 10, you can do things like drag running applets (written in Java or JavaFX Script) out of the browser and onto the desktop. Stuff that the other runtimes like AIR just can't do.

Romain Guy: JavaFX Script is an interesting language. It brings declarative and even functional programming to the Java world, which requires a mindset shift for many developers. JavaFX Script has two major issues to me. First of all, the language itself. Despite its qualities, the language is too foreign for most developers and is still evolving in major ways. On the other hand Silverlight relies on .NET technologies like C# and XAML while Flex relies on the well-spread ActionScript, which is very close from JavaScript. These languages are easier to learn and the skills acquired learning them can be applied to other products.

Then, there's the tools issue. JavaFX Script has a NetBeans plugin but you don't have a high-quality IDE as we have today for Java, C#, Silverlight, etc. Flex is not better in that regard but it offers a great visual builder integrated within the IDE itself. JavaFX Script doesn't provide anything that helps you create applications visually. Sun has promised tools targeted at visual designers but I highly doubt they will be able to deliver such tools quickly. Microsoft and Adobe (at least the Macromedia part of Adobe) have years and years of experience working with designers. Sun is a hardware and programmers company, not a designers company.

Chet Haase: New languages and platforms are funny things; they get adopted (or not) for all sorts of reasons. I think it's great that these kinds of facilities are being added into the platform so that they no longer have to be written from scratch. Heck, maybe we wouldn't have needed to write a book on how to do animated effects in Swing if they were that easy, or at least the book could have been a lot shorter. But there are other factors at play here, such as experience with the language, target market of the platform, existence of tools, and fickle whim. We'll see what happens when Java FX is final and developers and designers can really start hacking with it and releasing applications they've built.

Cay Horstmann: I asked just that question to Bob Brewin [a Sun Distinguished Engineer and CTO for Software at Sun Microsystems] a few months ago. "Bob, give me a reason why someone would switch from Flash to Java FX." He didn't pretend that there would be any technical or usability advantages (which I don't see either). He touted the fact that Java gives a completely open source solution, which appeals to large customers who like to be in control of their destiny. Very well, but aren't parts of Flex being open sourced as well?

There are reasons to use Java. A shop may just want to focus on Java skills rather than having to deal with the Adobe technology stack. Also, if you go beyond what Flash/Flex can do easily, then you fall off a cliff.

In my view, there are three ways to deal with this:

  1. Play to the strength of the Java market. Fix the Java language, API and tools to make client programming easier. Throwing yet another scripting language (FX) into the mix does not help.
  2. Compete like crazy with Adobe and Microsoft. Build up a competitive set of tools. But Java FX without rich media support is a non-starter. (Microsoft knows this -- they don't try to go head-to-head with Flash [yet], but they pitch the rich media capabilities of Silverlight and trot out NBC as a reference customer.)
  3. Offer something that is different and better. A simple way to write apps that work online + offline. Dev tools and frameworks that seamlessly produce Web apps + companion client apps. Web + mobile stuff that actually does something useful. Sun is far away from those, as far as I can tell. I raised the online+offline issue with the FX guys, and they effectively said "that would be nice, but that's not my department. Can I show you this cool transition effect?"

Ted Neward: I think in Sun's mind, JavaFX will be an equal competitor to ActionScript, XAML, XUL, Moonlight, or any other UI technology; I also think the community will more or less treat it as a non-entity, another example of Sun "throwing something against the wall to see if it sticks," like Sun has done with other technologies, like JXTA and Jini. Anybody else remember the Java Ring SDK that was the "hot ticket" many years ago?

Jim Weaver: I like the way that Josh Marinacci of Sun characterizes it: "JavaFX is sort of a code word for reinventing client Java and fixing the sins of the past." Some of the advantages of JavaFX are that you can instantiate, and call the methods of, any Java class. This means that any classes that exist in Java (e.g., middleware classes that handle the JSON protocol) can be leveraged by JavaFX. Therefore, developers that want to use rich-client Java will begin gravitating toward JavaFX Script.

John Zukowski: I've always viewed the Java programming language as just that, a programming language. People with a good background in computer science can do what they want with it and don't need something like JavaFX Script. To get more of a mass appeal and make the Java platform available for those without the core programming background, that's where things like JavaFX Script and all these other solutions come into play. There is nothing wrong with them. They work great for the right audience. I'm just not that audience.

Will it woo designers away from the others? I doubt it will woo anyone away from the others. What I can see is as more people need to choose a new solution from these three (and others), a portion of this new pool of users will gravitate to JavaFX script. Coming from a consultant background, it is hard to justify spending unbillable time learning something like JavaFX Script when you can get a reasonable rate using Flex or even Silverlight. Looking at a job board like Monster brings up one JavaFX post, 150-ish for Silverlight, and over 2500 for Flex, so there is definitely still strong demand for the others. Of course, if you are able to fill that one JavaFX job, perhaps you can charge an even higher rate.

Rich media and JMC

Although JavaFX Script goes a long way toward fixing the UI experience (such as simplifying animation), this technology doesn't address Java's inadequate support for rich media. If applets are to succeed in a RIA context, Java needs to also make it easy for them to play videos and other kinds of rich media, whose importance is evidenced by Web 2.0 sites such as YouTube and iTunes.

You might think that an updated JMF is appropriate for this media-playing task. However, as Chet Haase has pointed out, it would take a lot of effort to revamp JMF, which does much more than simply provide the means to play media. Furthermore, JMF's roughly 2MB footprint impacts the JRE's download size.

Instead of revamping JMF, Sun is pursuing JMC. This lighter technology initially targets media playback, but might eventually support tasks such as media capture and streaming. The idea is to support native media players where possible (to save time and money), and to support a Java player (for playing media on platforms that don't provide a native player). So, I asked the question: What do you think about JMC for rich-media applets

Danny Coward: We're beefing up the rich media support in the Java platform for Java and JavaFX developers alike. Better integration with the natively supported formats is just a first step, but there will be more to come. Including an all-Java player for rich media.

Romain Guy: It's high time Sun offered good video and audio support. However, I think this support comes way too late. It will make some desktop applications a lot better and easier to write, but it won't really help applets. I will surely have some fun with these media components ... when we get them.

Chet Haase: I'd put JMC clearly in the camp of features that Java needs to stay current. Video has become a checkpoint item in desktop and Web applications today. What was once an item on the wishlist for Java features has become, I think, a requirement; if Java can't support simple video functionality, then it can't be a player in the Web application space of today. The JMC feature is meant to address this requirement.

Cay Horstmann: Well, it will be if and when it is real. I have not seen anything about that since last June.

Native playback is probably the way to go because licensing players is expensive.

John Zukowski: I haven't heard much about the Java Media Components but if they are including enhanced players into the platform, great. This again goes back to the programmer vs. designer mentality. As a programmer, I could create a media player before (and have). As a designer, I would expect to just find something to use that doesn't require anything more than a URL or stream of what to play. It is kinda why projects like Apache thrive where developers make reusable libraries available for others.

OMS and OMS Video
After completing this article, I discovered Sun's OMS (Open Media Stack/Open Media System) and OMS Video projects announcement. According to Sun, OMS is concerned with providing "a free (open-source and royalty-free) complete media solution, including video, audio, transport, control, and content security." Furthermore, "OMS Video seeks to bring an updated royalty-free variant from the h.2.6x video codec lineage to the open source / royalty-free community." Assuming that OMS and OMS Video are not open source FUD, they appear to offer something that could benefit JMC, which (in turn) could benefit applets.

Authoring framework

Assuming that Sun achieves success with Java SE 6 update 10 (and up) JavaFX Script, and JMC, what else can Sun do to help applets get their slice of the "RIA pie"? One thing that is missing from the client-side efforts so far is an authoring framework, which would simplify the development of RIA-based applets. So I asked the question: Would you like to see Sun release a framework similar to Flex and Silverlight?

Danny Coward: It's funny you should ask that, but other than to say yes, I have to keep my lips sealed until JavaOne!

Romain Guy: In a way, that's what Sun is trying to do with JavaFX Script. And to be honest, I don't really want to see such a product come out of Sun. I was initially thrilled by this idea but it seems to me that since JavaOne 2007, when they first announced JavaFX, all the efforts at Sun have shifted from Java 7 and Swing to JavaFX. And with no real product and tools available yet, I feel like we, as developers, might end up waiting for something that may or may not be able to compete with other RIA platforms and waiting for updates on the technology still widely used out there, the JDK.

Cay Horstmann: Sure, that will be great. It's a tough act to follow in a short timeframe.

Ted Neward: No. Sun spends too much time working on client UI frameworks, and the fact is, the window of opportunity on that particular landscape has all but closed -- just as a good general needs to know when to retreat from a battle in order to preserve his troops and limited resources and find a different way to achieve his ends, Sun needs to accept that the client Java story is not going to be one that they're really capable of writing. They've spent all this time trying to create a community and ecosystem to compete with Microsoft's, now they need to have enough faith and trust in it to let it take ownership on this issue. If the community feels strongly enough about a client Java story, those frameworks and tools will emerge, and the Java Community Process can then pick one up, ratify it, and Sun can include it in later builds of the JDK. And if it turns out that the community doesn't care enough to put energy into that story, no amount of prodding or argument or innovation from Sun is going to convince them to pick it up, and the resources Sun puts into that effort will effectively have been wasted.

I think Sun instead should focus their corporate energy on what has gotten them to this point: Java on the server. Invest innovative energy into making XML messaging (Web services, ESB, what have you) easier on the Java platform, so that the position of Java-on-the-server is reinforced and defended. In essence, cede the battlefield to Microsoft and Adobe, whose battle over this space has just started. Sun can then watch to see who emerges, if a clear victor does emerge, and look to create interoperability partnerships with them to make it easier to get those snazzy new front-ends to talk to the Java-powered back ends.

John Zukowski: Yet another framework isn't necessary. While competition in the marketplace is good, the time when every company needs to try to offer solutions for every problem are long gone.

Chet, from behind the curtain

In addition to answering my questions, Chet Haase proposed one of his own: What do you think is the greatest thing about Java today? You might think that Chet's answer would focus on Java's platform independence, security features, or even its wealth of APIs. However, none of these answers even come close. According to Chet, the greatest thing about Java is "Duke. He's just so darned perky."

Can applets come, too?

Despite significant problems and a general disillusionment among Java developers, applets still have a presence on the Web. It's hard to say whether they will continue to be marginalized or will, in fact, make a comeback as a fundamental piece of Java's rich Internet development platform. Java SE 6 update 10 and up, JavaFX Script, and JMC are all tremendously promising technologies, though as yet largely untested. Even if these technologies revitalize Java on the client side, it's unclear whether applets -- a holdout from the "bad old days" of Java on the client -- will be part of the renaissance. So I asked my final question: Do applets have a future on the Java platform?

Danny Coward: With the upcoming releases of JavaFX for the desktop, and Java SE 6 update 10, we're really taking a big big leap forward into the rich client space. We've addressed the runtime issues of startup and installation. We're transforming the development model with a new language designed from the ground up for today and tomorrow's generation of rich client applications and a new generation of designers. We're finally bringing the level of media support to where it needs to be with the JMC project. We're rolling out a development model and runtime that because its based on and built in Java, will span multiple devices.

Applets are the central model for Java and JavaFX rich clients. Some people have predicted a renaissance for Applets in 2008. I think they are right.

Romain Guy: I think they will have a future because Sun will keep pushing applets but I think they should just be forgotten. Nobody really cares about applets anymore and with the free Flex SDK, or even Silverlight available on the major three platforms (Mac, Linux ,and Windows), I really don't see why we should even bother with applets anymore.

Chet Haase: Applets definitely have a future. In fact, they've had such a long history that that history will continue into the future. That is, there are many sites out there that provide applet games already that aren't going away. Also, many companies use applet technology internally and will presumably continue to do so.

I think the question is whether there will be any new movement toward using applets for consumer applications; will there be any new content, especially content that uses some of the new technologies coming out of Sun, such as Java FX and the Update 10 features? I frankly don't know. There was a real trend toward using applets many years ago, but that trend has gone elsewhere. There are so many alternate approaches out there for building Web applications; Ajax, Silverlight, Flex, and probably a lot more now and in the future. Will any of the changes in Java be enough to bring developers back?

I think the changes that are being made in Java are great, and a necessary part of keeping the platform current. But it's not clear to me whether they will be game-changing enough to make Java a player in the consumer space of Web applications again.

Cay Horstmann: Yes, if you are a Java shop, or if what you want to do exceeds the capabilities of Flash.

For that to change, Sun has to do a heck of a lot more heavy lifting than we have seen so far. I give them credit for trying, and I hope they succeed.

Ted Neward: Honestly, no, except for very small tightly-focused applications and/or controls to augment the HTML on the Web page. Mind you, I think applets should have gotten a better deal, given how limiting HTML is when compared to other technologies, and Ajax doesn't exactly offer a "lightweight" solution: running Gmail in your browser yields a memory footprint that's roughly equivalent to that of Microsoft Outlook. Trying to build an application that has a consistent user interface across the browsers is awkward and difficult, particularly as each browser release introduces new bugs, or fixes old ones and thus breaks the workarounds; this was a problem that applets never faced. But the industry fell in love with the 3270-esque nature of HTML, thus putting us on a long hiatus from elegant user interfaces as a result, and the pressure to fix the problems with applets in 1998 just evaporated.

Jim Weaver: I believe that Java and JavaFX applets will come back with a vengeance. One thing that will contribute to its success is the simplicity, elegance, and power of JavaFX Script. Another contributing factor will be Java SE 6 update 10.

John Zukowski: Applets work well as an advertising vehicle or for enhanced navigation where the solution is compact. Deploying full-size, client-side applications are better left to Java Web Start and other solutions where they are disconnected from the browser. Everything does not have to live in a browser these days.

In conclusion

Weighing the discussion generated by my questions for this article and my own experience developing a rich Internet applet using JavaFX Script, I'm optimistic that Sun's efforts to make applets a viable alternative to Ajax, Flex/Flash, and Silverlight will pay off, at least to some extent. While it is true, as some of the thinkers here have pointed out, that Sun is late to the game (overcoming problems that plague both browser-based applets and applications), Microsoft is a relative newcomer to the Internet arena and now has a big share of the browser market.

Rather than seeing applets dominating the other technologies used for rich Internet development, I see them as just another choice for getting the job done. Given reason to be confident that various applet problems have been addressed, RIA developers and UI designers are as likely to use applets as we are to use the alternatives.

Also see "The new applet experience" -- a short experiment in rich Internet applet development using JavaFX Script.

Jeff Friesen is a freelance software developer and educator who specializes in Java technology. Check out his javajeff.mb.ca website to discover all of his published Java articles and more.

Learn more about this topic

More from JavaWorld