Skip to main content

To the Top of the Food Chain

Posted by javakiddy on January 15, 2008 at 3:44 PM PST

One of the things which slightly unsettled me after the release of Update N was the frequent mention of how much better things would now get for Java applets. The subject cropped up again, in detail, during my post-holiday catch up of Java Posse podcasts.

To paraphrase Obi Wan Kenobi: "Applets, now there's a name I haven't heard in a long long time."

Like many who came to the platform in its early days, my first experience of Java was via web applets. Back then I was working on projects for Hewlett Packard — the only way to build Java code on HPUX boxes was to call the JVM embedded in Netscape 2! Boy was I glad when HP released a proper SDK!

While I recognised the potential of the Java platform (which it still hasn't fulfilled!) I wasn't mad keen on grafting it into web pages. Years later web designer friends would jokingly comment on Java's decline at the hands of Flash — no doubt they expected a robust defense of the applet platform, but that was the last thing I was ever likely to give.

The undoubted kudos and publicity Java received thanks to applets came at a heavy price: the term "Java" became synonymous with eye candy. Useful applets were few and far between compared to the sea of eye candy. It's an image which seems to have stuck in the minds of many, as I've found when pitched Java solutions to government and media clients. I sometimes think it's an easier sell if the client has never heard of "Java".

All this talk of applets has got me thinking: isn't it about time we moved Java up the food chain?

Survival of the fittest

Perhaps some Java folks never really got over the humiliating defeat to Flash during the latter part of the Nineties. No sooner is there a renewed focus on the desktop than people are extolling the virtues of the Java Kernel for applets.

My response is simple: "let it go!" Flash won fair and square — their technology was nimbler, better met the needs of the audience (who, if you hadn't noticed, were more at home with 'Photoshop' than 'Visual Studio') and had all the key features within easy reach (read: video!) Java applets were, and still are, an application development technology in a graphic design world. What do we honestly expect — a revival?

Sure, there's nothing stopping us creating our own Flash like development tool... except Flash's origins are very different to Java's. Born initially as a vector animation and graphics tool for the web, even now Flash still retains the feel of a technology who's users are more at home with a paint brush than a screwdriver.

This isn't to say that Java doesn't have a place in the realm of graphics and animation, but there is a difference between low-level graphics/timing APIs, and the applications which sit atop them. (Are you listening Microsoft anti-trust lawyers? Winsock != Internet Explorer :)

Besides, even if we came up with a development UI comparable to Flash, why would anyone want to switch? What must have functionality would force Flash users to abandon their hard earned skills en masse and join the Java camp?

By the pricking of my thumbs...

Ironically, while the Java camp plots its return to the web browser, Adobe have been steadily trying to get Flash away from the browser and onto the desktop.

Increasingly users are becoming restless with the limitations of the web as an application platform. Web 2.0 hasn't delivered the kind of rich interface experience people recall from their time with desktop applications. It is only natural that Adobe should wish to follow the herd as they move away from the browser and back onto the desktop.

But this is where Flash's heritage starts to work against it. The desktop isn't the web (obviously!) — while users do seem to favour more visually impressive UI's, they're also demanding a comprehensive widget library backed by plenty of functionality. Flash's UIs are still very much glorified web forms, and its API support for functionality outside of the web (crypto, heavy XML, desktop integration, file formats, network protocols, the list goes on...) is extremely feeble.

It makes me wonder why, given Java is currently sitting pretty at ground zero of the likely next big thing, anyone would suggest upping sticks and muscling our way against the flow of traffic?

Fixing Java

At last steps are being taken to address the JRE's download size and start up time, making the Java platform a far more attractive proposition for both the developer and end user. But there are two key issues which still need addressing: one minor, one an 'elephant in the room'.

The first issue is branding, specifically the amount of it.

No, this isn't a plea to increase Java's visibility through some clever marketing campaign — quite the opposite, we need less branding! The fact that a given application was written in Java needs to be hidden from the end user. From applet splash panels, to tray icons, to WebStart download dialogs, and so on: the end user mustn't have Java's 'alien' (non-native) nature thrust into their face.

After all, who are we preaching to? Regular end users don't care what their software is written in, but software publishers do care when their products are littered with tags and logos for the tools they use.

The second issue (and the aforementioned elephant) is video support, or lack thereof.

It can't have escaped anyone's notice that YouTube et al went with Flash for their embedded video component. Hardly a surprise, given the equivalent Java applet would have been a nightmare (even with the kernel.) What is it with Java and audio/video — why is it always such a struggle?

Top of the food chain

Whenever Java has lagged on the desktop the culprit has often been its fetish for re-implementing native components as bytecode. Flawless native look-and-feels and web content rendering was impossible, until we ditched our fixation with '100% pure' and reached down to wrap the native components. Java's attempt to re-write media codecs fizzled and died, and again the solution points towards leveraging native codecs rather than writing our own.

What use a 100% pure Java PDF viewer, when we can embed the native PDF viewer already available on the user's system?

Can you see where this is leading us? :)

Well, I began by talking about the demise of the applet, and how some would like to re-animate it. Coming almost full circle, I want to propose we turn this idea on its head (ouch, mixed metaphor!) Instead of embedding Java inside other applications, why don't we focus on embedding other applications inside Java?

In the 'battle to come' for the Rich Internet Application space, Java is in a very strong position. We already have an extensive developer community, oodles of API support, and age-old issues of deployment and startup are finally being addressed. Now we need only a few tweaks to WebStart, and a new media API, to really get the ball rolling! Compare that to the uphill job Adobe has ahead, turning Flash's web-centric functionality into a tool which could churn out a respectable RIA word processor or media editor.

Flash is heading Java's way again, but this time it'll be fighting on Java's home turf. But let's not get complacent: many a superior technology has fallen to weaker opponents who somehow caught the imagination of the public (and if there's one thing Flash is good at...)

Let us assume, for argument's sake, Java reigns supreme... Even as the World Wide Web's star begins to wane, and newer stars twinkle ever more brightly in the night's sky that is the Internet (who says I can't do poetry, eh?), Flash's future is still assured. It will always retain its place as a handy 'embed' inside other applications.

Can you imagine a desktop application in the not-too-distant future, where the help system consists not of boring text but rich vector/media animations? Those animations would be running inside an embedded Flash plugin, naturally... but what of the host app? Wouldn't it be spooky if it was written in Java?

Hmm... Flash movies, running embedded inside Java Rich Internet Apps — now there's irony for you... :)

Related Topics >>


I've been programming webstart apps for 3 years now. This was driven by the need to provide a rich user interface accessible over the web. Yes, I've had some issues with WebStart (desktop shortcuts sometimes stop working after updates, etc...), but overall it has been an excellent platform for development AND distribution. The biggest challenge was binding to the database. That's a lot of grunt coding. The solution I found was InsiTech's XTT and never looked back. With XTT you build your apps using Java/Swing and XTT binds, remotes and persists the data for you. Yes, Automatic bean binding. They have a free Community version you can check out. This is where Sun should be going.

Great post! Regarding splash screens... I don't know which focus groups or marketroids are fooling Sun into thinking "Java" or "j" has to be prefixed to everything. It's just too associated with tech. Although this isn't directly in line with your thesis, I think that the potential failure of JavaFX could be as related to the word "Java" in the name as anything else. Case in point: What rings better and reduces the risk of automatic dismissal by consumers and technologists alike: "FX and Flash compete head to head" or "JavaFX and Flash compete head to head"?

The solution is already there:

QtJambi and Java is really a match made in heaven. With Qt 4.4 it will be possible to mix Qt and Swing Components, we have all Phonon Backends and the whole great Webkitbrowser at our fingertips!

If SUN and Trolltech team up to propagate Qt for native, lowlevel and multimedia stuff I predict the war is over before it even begun.

I've never quite understood why Java WebStart didn't get more traction with developers. I'm at yet another company with a fixed user base (i.e. - not the entire world with a browser) and we have a Java web app that we're attempting to augment with AJAX to provide a better user experience. Seems like a better idea would be to give them an application via WebStart that has state rather than try to bolt state onto a web app.

I will say that the tide seems to be turning. I've run into a number of companies during my job search in the last 9 months that already have Java applications that are launched with WebStart. Swing skills, coupled with skills in designing services, could become the must have skills in the near future..

What use a 100% pure Java PDF viewer, when we can embed the native PDF viewer already available on the user's system?Because you can't count on your OS having a PDF viewer (I'm looking at you, Microsoft). I'm not saying it has to be 100% pure Java, they could have shipped a C library for rendering PDF, but I'm not sure how much difference it would have made.

Flash movies running inside a Java application sounds like a great idea, only don't rely on Adobe to do it. I like the idea of Media Components that some inside Sun are working on, and would like to see a gnash-backed flash player as a part of that.

I agree, the browser embedded battle was lost years ago and trying to open up a second front is just silly. The future is the return to the desktop and we need to get ready for that fight.

But the idea that apps need to look and feel native was wrong. ITunes proved that, and Webapps (esp. GMail) proved it again - people don't need native apps they need easy to use and understand apps.

What Java , Sun or the community in general needs to now is find the barriers to making these apps and hammer them down. Can we build an extension to Swing Application Framework for remotely served apps ? Can we make a remote persistence mechanism for POJOs ? Can we de-brand webstart ?

We can't afford to fight the wrong battle again.

@rbair: Platforms do not survive by playing nice with rivals.

That's rather draconian. Providing Flash/AIR doesn't have headway on the desktop I don't see it as being a threat. Certainly Flash offers functionality outside the traditional remit of Java -- if not so much in what it can do, certainly in the way it does it. If Java applications could harness that...

Platforms do not survive by playing nice with rivals.

kslater wrote: I've never quite understood why Java WebStart didn't get more traction with developers.
  • Bad documentation, focusing on things irrelevant for developers, and not demonstrating the advantages (aside from marketing-style claims how great the stuff is)
  • Cryptic user interface for end users (Where is "my" application installed? What is that Java cache thing? Java Application Cache Viewer, Java Control Panel? What on earth is that Java thing downloading now and why? ...)
  • Not a full installer (try to run WebStart from a CD in some random drive ...)
  • Having to mess with cryptic XML config files
  • Does not interact with normal installer on target system (e.g. on Windows WebStart "installed" applications aren't visible in Add/Remove Software menu)
  • Hard to use WebStart to install additional files together with the application (Sun's own JavaComm felt victim of this, it had an additional properties file which required a lot of messing to get it deployed via WebStart)

On a general note, I agree that Sun should finally let go of Applet and eye candy. Unfortunately, it doesn't look like this. E.g. every year at JavaOne Sun proudly shows yet another bunch of fancy eye candy demos. Eye candy, eye, candy and nothing but eye candy. What Sun doesn't do is to really work on the Java desktop integration. One desktop initiative after the other was announced during the last ten years. Every such initiative died a few month after the initial big announcement.

There would be hope if Sun would deprecate each and every applet-related API. If they would finally remove the deprecated APIs from Java, and if they would finally really work on desktop integration, media integration (JMF ...), instead of demoing eye candy.

It ain't going to happen. It didn't happen in the last ten years, it won't happen in the next ten years. It won't happen because it would require a fundamental change of the mindset of the people in charge of Java. Starting from the strategic decision makers who apparently have their priorities wrong or their developers not under control. And down to the developers who aren't finishers but quitters, and litter the Java ecosystem with half finished, badly thought-out, never completed APIs and hacks.

Did I already say it won't happen?

I think you're correct about giving up on 100% Java. When you start thinking about creating Java applications that can reuse the services that are already on the local machine (like the local spell checker, the media player, the PDF viewer, etc) then it won't be long until you realize that OSGi functionality needs to be included in the JRE. I wish Sun would give up on the stoopid Java Module JSR and commit to getting OSGi in v7.

Wow - projects for HP - you da man!

"And down to the developers who aren't finishers but quitters, and litter the Java ecosystem with half finished, badly thought-out, never completed APIs and hacks. " I find this a general problem with the java community at my workplace. Unfortunately there is too much evangelising about language x y z (insert ruby, python, perl, java or whatever) without focusing on what the languages are actually for i.e getting code out that runs (and can hopefully make the company you work for some money).