Is it ever acceptable to make a Java Applet part of an enterprise wide rollout?


News: Is it ever acceptable to make a Java Applet part of an enterprise wide rollout?

  1. 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 to anonymously post blazing condemnations of the corporate content management tool, and’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.

    Threaded Messages (17)

  2. 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?


  3. Go on...[ Go to top ]

    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?

  4. Go on...[ Go to top ]


    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....




  5. mobile apps[ Go to top ]

    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:

  6. Another option[ Go to top ]

    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.

  7. Another option[ Go to top ]

    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.



  8. mobile apps[ Go to top ]

    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:

    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.

  9. 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.

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

  11. folder Upload[ Go to top ]

    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.

  12. Baby + Bathwater[ Go to top ]

    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.

  13. JQuery[ Go to top ]

    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

  14. 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.

  15. quick to dismiss ?[ Go to top ]

    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. 



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

  17. Hi all, it feels strange to re-invoke this discussion after close to two years. But in fact I came across this page while investigating a challenge that - amazingly - could still require me to use Java applets, which I must say that I was never a fan of, now in 2014. I just came across a graph on BuiltWith ( showing that of the top million websites, only 2.3K (0.23%) used Applets in the beginning of 2013, and today that number is down by half to 1.4K (0.14%). Haven't heard any news about Oracle decommissioning the applet, but "dying technology" is definitely the right label. I thought it would be interested to air my present dillemma, as a theoretical case at least, and perhaps even some of the original participants might have some light to shed. 

    I am considering integrating a structured-document OCR engine like or (used to recognize things like business cards, passports, driver's licenses etc), with a browser based application. In my scenario the clients purchase the software together with a special card scanner, but there is a requirement to run the UI itself in a web browser. There is typically one central workstation with the special equipment installed, and other workstations on the network are required to show the scanning results within a browser (presumably, accessing the central scanner over the LAN). So, like in other cases discussed in this thread, Javascript on its own is not an option because I have no access to the scanner's device driver, and to make things worse, I sometimes need to access it as a network device. I've tried to investigate and still don't know what are the pros and cons of an applet vs. Java Web Start (which is obviously the preferred option as far as platform compatibility and future support is concerned), when it comes to accessing devices via a LAN. But I'm definitely going to need some Java element to drive these scanners, such element interacting with a modern Javascript framework driving the UI. I definitely will not want to use Swing, Adobe or any of the other options advocated above for the UI because of lack of flexibility and desire not to lock myself into "specialized" technologies.

    So - the same question repeats several years later. Any reason to really use an applet in this case? Perhaps its stronger device manipulation capabilities will make it the better option? Or the fact that it runs inside the browser with a smaller footprint and doesn't require me to run in the Java sandbox? There still seem to be edge cases in which an applet will have the advantage. Wish I knew if I was one of them :)

    Will be happy to hear any insights from the community.
    -- Sarah S.

  18. Hello,

    A couple of years back I worked on a web-application which had quite similar specifications; the application had to be able to interface with a number of devices(electronic scales, distance-meters) which used serial and bluetooth communication.  It had to be able to pull data from the devices, as well as listen to data sent by the devices.  Java applets enabled us to do this quite easily; they ran in the background (without any UI) and handled the device communications. Communication between the applet and the browser is also relatively straightforward; you can directly invoke JavaScript functions from the Applet.

    The trickiest bit of the development was actually stabilising the communication with the devices. Communication with hardware needs a lot of fine-tuning; the page would hang, waiting for replies from the devices, but these had nothing to do with actually using an Applet.  

    Another issue we had was managing the loading and destroying of the Applets; this was quite important in our context, as loading and destroying the applet meant synchronising and desynchronising with the devices (especially the Bluetooth devices).  The application used JSF, and initially, often when reloading part of the page, the applet would reload as well.

    To conclude, the application is in production since a year now and has taken over a million measurements, and we have never had to modify the device communication; so it seems using Applets was good decision.

    On a side note: I actually came across this post while researching JavaScript-less solutions for rich internet applications.  I had been wondering why Java applets were not used widely used in enterprise solutions; they (seem to) offer all the tools needed for building web-applications cleanly, in a strong oo language (i've actually worked on back-end-Java projects for the best part of my short career).  It is a far cry from the zillion java web-application and js frameworks which (imho) are really only hacks and convoluted workarounds implemented to make the browser do something it was not designed to do (and a nightmare to develop with).