Rick is a DZone Zone Leader and has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

Java Applets "Dead Man Walking?" Is a Comeback Impossible?

04.08.2008
| 14814 views |
  • submit to reddit

This evening I read a provocative piece on a blog by FunkyCodeMonkey, the thinking monkey. (I can't tell you how  amazed I am that a monkey can actually write this well. They sure have come a long way since Yerkish!) Anyway, the piece is very brief, and the title sums it up "No Last Minute Comeback for the Applet." I'm basically quoting it in its entirety:

I’ve been playing around with the Flex 3 builder lately and I’ve come to the sad conclusion that JSP’s future role in the java webapp will be severely limited and the venerable Java Applet is already a dead man walking. Flex has a interface that seems, so far, seems to be much easier to use than even the most modern Swing tools. It’s easier I think because there is only one GUI toolkit. No SWT vs Swing battles happening here. The Flex tool chain seems to have been made by a team made of both engineers and designers. A nice change of pace from what comes from Sun, IBM, Oracle and the rest of the Java sausage party.

While a part of me wishes it weren't the case, I must admit that FunkyCodeMonkey's position has a lot of strength (except for that gratuitous "Java sausage party" line.) Flex is really well thought out, and I have been impressed by how much can be achieved at the UI level with very little code and with strong support from GUI design tools. It took years for Swing to get anywhere close, but Flex and AIR are just getting warmed up.

On the other hand, there's a lot of work being invested into the presentation layers of  the upcoming Java6uN.  Sporting improved look&feel and hardware acceleration, Java6uN may be a formidable contender that gives Java new legs in the race. Is it too little, too late? Is the Java Applet (and web-delivered application)"already a dead man walking" regardless of what 6uN may deliver?

Tags:

Comments

Fabrizio Giudici replied on Wed, 2008/04/09 - 12:48am

It's difficult to say. But, first, I'd say that I don't believe to anybody categorically saying either "applets are dead" or "applets are going to beat Flex". Nobody can predict the future so certainly, because while it's true that Flex has two big advantage points 1) it's a nice integration of engineers and designers and 2) can be installed easily, Java is a much more powerful language and environment. For instance, it can do real multithreading and there's a huge availability of components, software and frameworks. The latter point being the most important, it's really critical to see whether JSE 6 Update N will deliver what has been promised.

 But there's another point. From my perspective, Applets are really unpopular for applications that deploy to the end user, while there are no problems if you're going to deploy in controlled environments (e.g. clients in a managed network). In my career from 1996 up to today I've always seen at least one applet per year in a project I've been involved in, even though I didn't work on all of them (up to a couple of years ago I was really focused on the server side). In all the cited projects the Applets have been deployed with success. In this segment point 2) can be addressed easily because computers are administered and point 1) is not so important since the human operator is not an end user - in any case, I'm seeing customers that are pretty good in delivering decently designed stuff from the graphical point of view, especially since when NetBeans Matisse is available and after the success of the Filthy Rich Clients book by Romain and Chet. Once point 1) and 2) are not an issue, Java beats Flex hands down, since the language is much more powerful, as I have already said. A third critical point has been the AWT Thread issues that did cause some troubles, but in the latest years I see that customers are better advised about that. So I dare to say that it's likely that both Applets and Flex have a future, what I can't really predict for sure is which will be their strength ratio. Note that I didn't ever cited JavaFX or the graphic design tools that Sun might deliver, since we are still waiting it is completed, that in any case might have a role in this battle.

Ian Griffiths replied on Wed, 2008/04/09 - 1:30am

No, there is a fundamental misconception here: Funky Monkey is under the impression that Applets are used to use Swing rather than HTML/CSS. Nothing could be further from the truth!

I have frequently used Applets in projects, but NEVER because I prefer Swing (although I do personally), but because I need to do something portable that I can't do well enough or fast enough in JavaScript.

One case in point was the encryption for an e-voting project. The requirements of the security auditors were so stringent that we were forced to use an Applet to do the calculations. Our customer was very worried, fearing an avalanche of phone calls: they got none. Over 90% of machines have Java enabled today with most others willing to download the JRE if a government agency suggests it (I suppose the others went to plolling stations or voted by post).

An amusing point of the aforementioned project is that the original project was developed using Swing. During the tests, many users expressed disquiet at the way the look and feel of their browser had changed from the previous pages. We then had to write an interface using the java/JavaScript bridge to manipulate the browser DOM and generate "native" components!

We have used this module on numerous occasions since then as it gives us the computational power of Java and the look & feel of the specific browser being used.

In practice, Applets are useful when complex validations or calculations are necessary. These include:

  • Encryption/decryption
  • Complex validations that are easier to write in Java with a good IDE.
  • Simulations, data conversion...
  • CPU-intensive calculations that you don't want to run on the server
  • Anything that will avoid useless round-trips to the server
  • Dynamic 2- and 3-D graphics
  • etc.

Obviously, using some sort of framework makes things easier.

 Ian

Konstantin Chikarev replied on Wed, 2008/04/09 - 1:59am

I am working with Flex and I don't like it for one reason. Flex isn't java technology and every Java object translates into ActionScript object. I can't make remote calls from Flex without recreating new object from existing by manual copying all properties.

Mike Dee replied on Wed, 2008/04/09 - 2:10am

I believe Java applets are a great technology, but largely mis-understood.

See http://mdichi.wordpress.com/2008/04/09/where-are-the-java-applets/

 

Naiden Gochev replied on Wed, 2008/04/09 - 2:12am

Swing is hard to write yes thats true but swing is cool swing have many many components swing have nice ideas. Flex making of gui is easy and fast yes but coding on C# or WPF is easy too ? If you ask me applets will be fine with Update N They start very very fast even on coldstart of the jvm maybe the only problem si that swing programming is harder so maybe JavaFX will help there or eFace ( yes i know that it uses sWT but for now.. ) or somethink like Groovy's Swing Builders ( grovyy can run on applet ).

Mike J replied on Wed, 2008/04/09 - 3:00am

Java applets are the reason I started using and supporting Java more than a decade ago. Unfortunately, the technology has been a disappointment, for several reasons

  • The available toolkits just aren't very good: Swing is a pain to program, and AWT is too simplistic. (Note that I understand Swing, I just think its APIs are badly designed.)
  • Applet/browser integration is pretty bad.
  • As a plugin, Java is bloated, slow to start up, and a big download.
  • There's a lot of functionality missing or only available as plugins for things people want to do in applets. Something like playing a video in an applet should take 10 lines of code and run everywhere; with Java, it doesn't.

If applets are ever going to have a chance, Sun needs to:

  • create a special "applet" edition of the Java runtime that incorporates exactly those APIs good for writing applets
  • develop an applet GUI toolkit, something that's much easier to program than Swing and targets specifically running inside browsers
  • include a scripting engine in the Java Applet Runtime (Jython or JavaScript) that makes writing applets much easier
  • improve browser integration
  • make startup instantaneous and reduce memory usage
I doubt it's going to happen. Sun is much too ideological to actually roll up their sleeves and fix this sort of thing.

Sébastien Letélié replied on Wed, 2008/04/09 - 3:38am

Applet is not dead for a major reason : the powerful of Java on the client side. A simple example : i made an application for physician, in France they have a card to identify them. If i want to use this card to login on the web app, Applet is the only tehnology i can use to do that. It's impossibile with Flash Player or Gears at now.

What is sure is that Applet is not the good choice for RIA : plugin too much bigger and no easy to install for final users, no design tool for Swing, no collaborative tools with designer (it's the power of Adobe). But if you need specific used on web app with OS interaction on the client side (COM port, Bluetooth, ...) Applet will stay a good solution and the only one which integrate security aspect (by certificate) for this type of used.

John Bridges replied on Wed, 2008/04/09 - 4:42am

I'd say the role of the traditional applet is dead. The reason for the applet was to provide rich functionality to the (then) rather basic Browser. As many will have noticed the modern Ajax apps aren't short of rich functionality within the browser itself.

Where there is opportunity I think is in the use of "domlets" - applets which manipulate the browser DOM for their UI capabilities. In fact if I was a betting man I would put some money on the "browser" supplanting toolkits such as SWING and SWT in the provision of desktop apps.

Richard Osbaldeston replied on Wed, 2008/04/09 - 5:07am

My worry is that the exsiting signing depolyment issues will still haunt "Java 6.0 Update N". Perhaps more so as much of the Swing/2D changes are geared towards JavaFX. The intergeral JavaFX binding will no doubt use reflection in some fashion (beansbindings?) and so will need sigining if its to devlivered via Applets or Web Start. So Verisign stands to be a big winner here if everything suddenly needs signing (Isn't this why the JavaFX articles dont often provide runnable demos?).

So we're back to age old Applet or Java Web Start issues, and wheter to go for "All Permissions" or use Web Starts finer grained security permission requests. My problem with the "ask for to permission to do x" approach is that you're coupling to JNLP - so no option to run as a normal standalone executable jar. Plus you make the user suffer the unpopular Windows Vista UAC nag dialogitis (not an attractive option for sexy RIA widgets either). "All permisions" is of course a security risk and we lack useful gradings in-between (well there is one, but its pretty limited - too limited for reflection). Unpinning the standing approachs is its almost impossible for the user to determine what kind of risk they're actually taking. The permisions have the most random names and even I (as a developer) don't fully understand their individual let alone combined limits. I'd rather be able to say "Yes run this app, but only on my own terms" for example disallow access to the filesystem or network outside of my usual java.permissions area.

On the customer front you stand to scare them to death with the Java Web Satrt security warnings when the application starts. Can't help but feel the whole process isn't well suited to these sexy little semi-transparent, round-edged RIA widgets. Perhaps more of a problem is that behind that dainy little widget will be hiding the same old honking great JVM sucking up a disproportante ammount of resources. I'm proballaby being old-fashioned worrying about memory and cpu overheads.. but Java dosn't strike me as particuarly well suited for running lots of little RIAs. Havn't heard of the MVM in an age, but even then you'd have to be using a good many applications at once. Java's only real advantage is it's cross platform byte compatibility, but for Applets 10 years on we've got a host of (better?) alternatives in most situations that can offer the same compatibility and don't always require some arcane platform to be pre-installed (jre penetration still seems to be an issue).

 

Robert Enyedi replied on Wed, 2008/04/09 - 5:39am in response to: Mike J

[quote=mikej924]

If applets are ever going to have a chance, Sun needs to:

  • create a special "applet" edition of the Java runtime that incorporates exactly those APIs good for writing applets
  • develop an applet GUI toolkit, something that's much easier to program than Swing and targets specifically running inside browsers
  • include a scripting engine in the Java Applet Runtime (Jython or JavaScript) that makes writing applets much easier
  • improve browser integration
  • make startup instantaneous and reduce memory usage

I doubt it's going to happen. Sun is much too ideological to actually roll up their sleeves and fix this sort of thing.[/quote]

Mike, I think Sun has anticipated your needs :-) What you are saying sounds exactly like JavaFX running on Java SE 6 Update 10. Now even if one would use JavaFX, a powerful authoring tool would still be needed.

John Denver replied on Wed, 2008/04/09 - 6:41am

One thing I don't like about Flex is the mix of MXML with Actionscript, It can use code behind but as always I will find like this mess kind of projects all over and it is a pain in the neck to maintain or debug. Flex doesnt follow patterns and I think is just a big mess.

The other day I installed Firefox on Vista but for some reason I couldn't install flash plugin on it. I don't trust this kind of solution that maybe Joe also can't setup his flash plugin or it doesn't have the lastest plugin. 

First it was Rails and now the community searching on Flex?, I will say better don't fool around and continue to work in Java, applets are not dead and as many said wait for J6uN and JavaFX.

Web programming with markup as JSP will have it place in the future and for a long time, Some users don't like the idea to bloat their browser or install 3rd party plugins, they just want it just works with a simple browser. Users wants simple and easy to use "It just Works". Users in this times they don't want to deal with deployment's, installers, PC requirements, so on. That's why we moved from desktop and client/server to the Web and Distributed.

Andy DePue replied on Wed, 2008/04/09 - 10:35am

I've said it before and I'll say it again, never underestimate the power of an excellent designer tool and solid video support - two things still lacking from JavaFX.

Carl Antaki replied on Wed, 2008/04/09 - 12:06pm

Applets can make a come back with JavaFX if Sun releases a quality designer tool for JavaFX. The new plugin speed needs also to be improved if it takes 1-2s to launch the JVM it won't cut it for RIA consumer apps, Java needs to start as fast as Flash but I don't know whether this can be done.

Mediarazzo replied on Wed, 2008/04/09 - 12:09pm

I had the good fortune of working on several projects that used Applets as recently as 2005. I also had the misfortune of having those same projects adopt Flash as the primary solution.

The gap between Flash and Applets, in terms of development and deployment, is huge. Much larger than most people want to admit. Flash is vying for the "Can't get fired for using Flash/Flex" mantle. Sun's current effort to fix things, while welcome, don't even match what Flash has been doing for years. Releasing a consumer-friendly JRE is not nearly enough. Sun needs to be addressing today's decision makers, that is, business people and designers. No comeback will happen without them. And as Andy above states, tools and media are vital. In fact, they're deal breakers.

No tools, no media, no ease of deployment? Then no big future for Java in RIA.

Carl Antaki replied on Wed, 2008/04/09 - 12:26pm in response to: Mediarazzo

You're right. Sun has a great technology but lacks the designer knowledge, the latest article on java.sun.com http://java.sun.com/developer/technicalArticles/scripting/javafx/ria_2/ make you say what's so new about JavaFX, the articles should show instead how to create stunning GUIs using JavaFX, we need people like Romain Guy and Chet Haase but unfortunately both of them have left. Synth is a great example of a good technology that was never used because of the lack of tools available.

Matthew Perrins replied on Wed, 2008/04/09 - 5:46pm

I have to confess I am in the camp that Applets and Java as we know on the client is dead. Adobe has executed its as simple as that, they have built a small foot print install runtime will all the sexy features needed. I have just started to code in Flex Builder and I am impressed at how easy it is to use and be constructive. Flex and AIR is a good story for RIA and Rich Client solutions. I think the fact that Java didnt wake up to the power of the 3 key OS graphics engines and W3C just didnt react quickly enough is the reason Java is lagging. I just think it is way to late for Applets to step up to this space, they could have 3-4 years ago once WPF, XGL and Core Anminations on Mac OS arrived, but the Sun guys still couldnt see Java talking native Widgets. Anyway, all the interesting containers Silverlight, Flex, iPhone etc are all using native level OS calls to get the job done, I cannot see Java or W3C getting their heads around this for a while, maybe Eclipse E4 might be the Desktop UI app platform, just maybe ?

Cheers


Matt

Vic Cekvenich replied on Wed, 2008/04/09 - 8:26pm

It's quite simple, flex acction script 3 (latest) is deployed on 4 billion users (http://www.onflex.org ) and couting.

 Easy to deploy.

 Java Webstart/applets later version is deployed on hundreds of end users and very hard and cofusing to deploy.

 Java 7 "easy to deploy for consumers" has mostly visible help for "setup.exe" type apps(and very few resources spent implementing, vs marketing noise), very litte for applets that would help catch up to the 4 billion end users. Just look at the rate of new addoption on onflex.org for action script 3 vs rate of new addition of latest run time for applets.

 As a devloper, I don't care how hard it is, show me the end users!

ff aaa replied on Fri, 2008/04/11 - 7:46am in response to: Vic Cekvenich

dude. there are far less than 4 billion computers in the world.

Robert Buffone replied on Fri, 2008/04/11 - 1:47pm

The problem with Java on the client is a failure to separate the deployment of the clients with "Applets" and the underlying way of developing the applications. The applet deployment mechanism is a fairly robust way to initiate application in a secure sandbox. It does have flaws, namely speed of startup (Fixing in Java 6), but nevertheless its pretty good.

I wrote a article on how Nexaweb (full disclosure - I work there) overcame the deployment issues as well as other issues. http://dev.nexaweb.com/blogs/nexablog/?p=9. The result of fixing the issues with client side Java has resulted in over 7000 deployments of Enterprise applications with Client-side Java runing in a browser.

Java provides an increased in processing power and richness of application over Ajax or Flash-based applications. The other benefit is that there are way more 3rd party software, tools and components that can be used with Java.

Mediarazzo replied on Fri, 2008/04/11 - 5:22pm in response to: Robert Buffone

You make a good point but I think the whole Applet/client discussion misses the larger point. The primary deployment problem is not a tech issue, it's a business issue.

The virtual machine is part application, part operating system. Sun, however, treats the distribution of the VM as an application (relying on developers who aren't the greatest channel) when they should treat it like an OS (taking care of distribution themselves through deals). As a result, there is scattered support for Java on the client.

Macromedia avoided this mistake and took responsibility for Flash on all major platforms. The move paid off. Deploying a Flash application is really no different than deploying Windows application. Pick your target platform and go.

Sun can get back into the game but my guess is they'll come up short on the business end. Fixing the tech problem is the easy part. Pounding the pavement, knocking on the doors of Dell, HP, Gateway, etc., ensuring the latest Java goes out on every machine is where the difference will be made.

Dmitri Trembovetski replied on Sat, 2008/04/12 - 3:44pm in response to: Mediarazzo

> Pounding the pavement, knocking on the doors of Dell, HP, Gateway, etc., ensuring the latest Java goes out on every machine is where the difference will be made.

 

What makes you think this isn't being done? Go check the machines in your

local electronics shop, see how may of them have Java preinstalled.

 

At least here in the US most major pc manufacturers have Java preinstalled. (although most

have java5 last time I checked). 

 

Dmitri

 

Mediarazzo replied on Sat, 2008/04/12 - 9:34pm in response to: Dmitri Trembovetski

Allow me to clarify. What I should have said is that Sun needs to *visibly* tout Java desktop success (including the fact they are pounding the pavement to get deals). Is this being done right now? Who knows. The real issue is, do the right people know it's going on.

And why is this important?

Ask yourself how everyone knows that Flash has a 95% penetration rate on the desktop. Because Adobe makes it a point for everyone to know, including the business people. Now what is Java's penetration rate on the desktop? Don't seem to hear much about that. Googling around (I tried: Java desktop penetration rate) reveals that most penetration numbers attached to Java are more than three years old. And even then, they were still behind Flash.

It's one thing to be on a tech board, with tech people, and say go to your local electronics shop and do such and such. That response won't fly when it's time to convince upper management to use Java, especially when they all know about Flash's availability.

Robert Buffone replied on Sat, 2008/04/12 - 9:43pm in response to: Mediarazzo

@Mediarazzo

I completely agree, Sun needs to get out their and put visible effort into the pushing desktop and web-based Java clients. The problem I see is that unless it comes from Sun they don't like it. If it isn't swing-based the Java pundits bash it. I remeber back to the conversations between swing vs. SWT. IMO - who cares. Choices and different approaches are needed, especially in client-side computing.

Mediarazzo replied on Sun, 2008/04/13 - 1:05pm in response to: Robert Buffone

Right. Lots of time and energy bashing each other. Very little time and energy informing the world outside of Java that Swing performance had actually improved. That's called poor focus. Something I don't think Sun has improved on.

Vic Cekvenich replied on Sun, 2008/04/13 - 3:46pm

Ahmet, click on the link I gave and see how many installs they have.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.