Would you ever make a Java Applet part of an enterprise wide rollout?

I certainly wouldn’t. As far as I’m concerned, Java Applets don’t have any place in a modern enterprise design.  Any functionality you need from an Applet can be achieved by intelligently applying JavaScript and leveraging existing JavaScript libraries, and not doing so is a disservice to your users.

Architecting a design with Java Applets?

Don’t get me wrong: I love Java; certainly more than the average guy on the street loves it. But if I was sitting in breakout room, and the hired gun tasked with architecting the solution suggested that a key part of the design involved developing a Java Applet, I’d laugh her right out of the room. I simply have no tolerance for Java Applets.

Of course, in 2012, one question you might be asking yourself is 'why are we even talking about this.' Well, pushing this topic to the fore is some research going on at TheServerSide into various enterprise content management solutions. Disturbingly, a large number of products in the content management space actually use a Java Applet for creating and editing content.

The Java Applet experience: A user's view

TechTarget, the parent company of TheServerSide, uses Vignette as their content management tool, and Vignette is one of the vendors that provides a Java Applet for content editing. If I was to describe how I personally feel about doing content creation and content editing in Vignette, I’d have to describe my feelings as ‘venomous hate’, and much of this venom comes from the usability issues surrounding the Java based editor.

I own two laptops and a desktop computer, but the Vignette editing page only works on two of my three computers, and even when it’s working it is flaky. And on the computer where it does work, it will apparently stop working if I upgrade my JVM from some obscure version six increment of the JDK. If the Java installation updates my JVM, which a little icon in the lower right hand corner of my screen reminds me every time I reboot that it is wont to do, the Vignette editor will then not work on any of my three machines. That’s what life is like for the end user when an architect makes a Java Applet the central part of a distributed design.

But as was said earlier, it appears that the Java Applet editor is not a cancer that is unique to Vignette. IBM in their IBM Lotus Rational Lenovo VisualAge WebSphere Web Content Management tool, or whatever they’re branding it these days, also makes a Java based editor a central part of their user disperience (UD). Have you ever heard the term: ‘putting lipstick on a pig?' In this case, it’s more like slapping the pig with a skunk.

Java Applets vs. JavaScript

Given, there was a point before the time of enlightenment in which Java Applets could do things that were impossible with other web based technology. But that three week window passed us by in about 1998, and enterprise software needs to keep up with the times.

When I question the effectiveness of the use of the Java Applet editor, I’m often told that only a Java Applet can perform the complex tasks associated with rich text editing. Of course, I then I go over to blogger.com to anonymously post blazing condemnations of the corporate content management tool, and blogger.com’s script based editor provides me all of the functions available in the Java based editor, with the additional benefit of the fact that it’s fast, responsive, and not only does it work on all three of my computers, but it also works in all four of the browsers that are installed in each of the three machines.

As I put together my assessment of the popular content management tools that are servicing the server side market, any content management tool that makes a Java based Applet the cornerstone of their content editing experience will be getting a big red raspberry, and will not be recommended. I simply can’t imagine recommending any software that is built upon technologies that I would never use myself when architecting an enterprise solution. Java is a great programming language, but I have no time whatsoever for flaky and poorly functioning Java Applets trying to run within my browser, and nor should anyone else.

What if you need your application to interact with client side devices like a printer, com port, USB, etc or use native code on the browser side?

Go on, I'm listening.

You'd put this in an Applet? My guess is you would need to have a serious control over the software the end users have on their machines, no? Perhaps more viable for smaller corporate offerings?

Hi

Imagine a browser based point of sale (POS) solution. The POS interacts with a printer and a bar code scanner. With Javascript you simply do not have an API to interact with those equipments.

One possible solution for this scenario (not the only one) is to have an Applet serve as a brooker for the local devices, and have javascript control the Applet brooker.

Keep this in mind that:

- Applets allow you to overtake security restrictions when necessary (e.g. read/write from/to filesystem) and interact with local devices

- By using an applet you are not required to use the AWT/Swing APIs for the view, it may have just have methods invoked via Javascript, keeping your view in HTML.

Of course if one tries to build the entire site inside an Applet, it may not be the best idea....

Cheers.

android, flex etc  are more efficient than java applets, thouh these are very huge to study. Probably there will be more mobile frameworks than java applets: http://en.wikipedia.org/wiki/Multiple_phone_web-based_application_framework

Another option would be Java Web Start and Swing or JavaFX based applications. That's how we've implemented our client facing financial solution.

I can't argue that JavaScript isn't powerful and capable but I'd far rather maintain a million lines of Java Code then a million in JavaScript.

I've also experience my share of browser issues with complex JavaScript based applications.

I can't argue that JavaScript isn't powerful and capable but I'd far rather maintain a million lines of Java Code then a million in JavaScript.

Yes, but it's more line 1 million lines of Java to 20 million lines of JavaScript.

Stan

android, flex etc  are more efficient than java applets, thouh these are very huge to study. Probably there will be more mobile frameworks than java applets: http://en.wikipedia.org/wiki/Multiple_phone_web-based_application_framework

Are they more efficient? Who says that? Please back up your claims.

So, because you have some examples of bad applets (I know there are a lot of them), you suggest to use proprietary tech (flex) or something totally different, that doesn't run in a browser. Applets are a solution to some problems. They just shouldn't be used when not necessary.

It's not Java Applet's technology's fault that Vignette didn't update their app to work with the current version of Java. If anything, it's easier to maintain Java Applet over time than Javascript. Javascript varies across time and browser implementation, while Java varies much slower than Javascript and doesn't vary with the choice of browser.

Applets are OK only if you still use Vectors and Hashtables.

To upload the content of folder (user need only to select  a local  folder) can't be implemented via HTTP without applet technology. If you have a workaround based only on HTML tags or javascript I am interested.

No, you cannot do everything [today] in JavaScript/HTML that you can do with Java (or something like it).  The same is true the other way around. Sure there a problems with applets. Do they have a place in "modern enterprise design" design?  Should you exercise caution? Yes.  Do you call JavaScript modern? I don't.  I don't consider HTML to be that modern either.  Viewing only the applet vs JavaScript is like only looking at the tip of the iceberg. 

As stated in other posts, you can yet the functionality of Applets by using WebStart.  

Anyway when you have computers, humans or computers and humans, something is going to go wrong.

JQuery makes JavaScript a whole lot less painful re cross-browser/version differences and amount of code to maintain, and as other posters have mentioned, you can call a Java Applet from JavaScript to access services that JavaScript cannot

Maybe applets are not the best tool for the job. Maybe Vignette would benefit from using JNLP/WebStart , maybe fat client. Either way, I would not say that one should not use applets - they are just tool, which must be used right. And yes, it's Vignette fault that applets are'nt working.

As in everything in life I think you need to use the right screw-driver(tool) for the right screw(problem)... 

Applets still have their advantages over Javascript in some cases. 
Creating a very sophisticated client, with lots of computational work on it, like performing analysis, or any kind of CPU consuming task - applets which run on the JVM can use Swing Worker threads to perform work in the background unlike Javascript these days, which is running single threaded. 

Not to mention the vast richness of 3rd party libraries you could use when you're writing an applet, whether it is for XML parsing, local caching (although this could be resolved using HTML5), graphics, etc...  

I wouldn't say Applets are totally history, yet. 
There are great alternatives today for writing Javascript web app front ends, in Java with GWT for instance. But as i said, applets still have their benefits, sometimes. 

http://tech-drum.blogspot.com/

http://keepvid.com

So there is legitimate cases for java applet.  Maybe you can do it with javascript too.  But I like the way it is now.