No Longer the Applet of the Developer's Eye

I recently noticed that applets are now, to use a Monty Python analogy, the Norwegian Blue of client-side development.

If you go all the way back to when Java was being developed, it was an applet that caught everyone's attention.

You may also like: Java: Getting Back to the Browser?

In early 1995, John Gage , Director of Sun Microsystems' Science Office, was heading to Monterey to do a presentation at the TED conference . The demonstration he planned was of a new web browser called WebRunner (the name being derived from Blade Runner ).

This included new technology that would, "bring the static Web to life." James Gosling went with John to handle the demo. He moved the cursor over a color 3D molecule image in the browser, clicked on it, and rotated the molecule back and forth. The entire audience, who had not really been paying much attention up until this point, went "Aaaah!" The web as we know it today, with all its interactivity, was born. And all thanks to an Applet.

Being a collector of arcane technology and related things, I still have my first Java CD from when I joined Sun in 1996.

Included in the picture is my copy of "HELLO WORLD(S)!" from which I drew details of John and James' demo.

In addition to having a copy of Netscape 2.0 and JDK 1.0, the CD also has various applets, including the MoleculeViewer . (I had planned to install all of the CD software but the system requirements are "Any SPARCstation with Solaris 2.4 or later," which I don't have). In order to run the applets, I initially tried using JDK 1.2.2 on a Linux machine but that wouldn't run because my machine was 64-bit and JDK 1.2 did not understand an architecture name of x86_64.

Even after fixing the .java_wrapper (remember that?), it turns out that the  libc is the way to modern and the Java executable just gave a segmentation violation. I switched to JDK 8 and was reminded that not all classes compiled with JDK 1.0 will run on a JDK 8 JVM due to a security fix introduced in JDK 1.1.2. (Very early compiled code from JDK1.0prebeta1 does not always set the  maxlocals value correctly, resulting in a  ClassFormatError ).

Having recompiled the source files with JDK 8, the applets ran happily using good old appletviewer . I've included a couple of screenshots. (Of course, it would have been great to include it embedded in the blog webpage but, as we'll see, that wasn't going to work).

As history has shown, the first Eureka demonstration did not lead to the situation today where all web-based applications use Java. In fact, it was quite the opposite. The Java runtime was initially integrated with Netscape , the most popular browser in the late 1990s (anyone else remember having to pay for a browser?) There were a number of reasons that prevented applets from achieving the potential they initially suggested:

• Late 1990s PCs were not that powerful or had that much memory. It seems crazy today but, in those days, the memory of a typical desktop machine would have been somewhere between 8 and 64Mb. That's megabytes , not gigabytes. With JIT compilation not being introduced until JDK 1.2, and garbage collection being rudimentary, the performance was not what users wanted.
• If an applet needed a specific version of the JRE to run that was not installed, it needed to be downloaded before the applet could start. Again, late 1990s modem Internet speeds were typically 56kbit/s . That meant a long wait for the Java runtime (JDK 1.1.8 was 36Mb, which took an hour and a half to download!)
• Security was always an issue. Applets ran within the sandbox security model , preventing them from accessing things like files on the hard drive, network connections, and so on. Often what an applet needed to do required additional privileges, which required a trusted, signed applet and for the user to grant permission through a dialog. Most users didn't understand the implications of this so simply accepted any applet that wanted additional privileges leading to obvious exploits.
• The applet execution environment through browser plugins and APIs was also a perennial security problem. The majority of security-related issues that Java has had over the years have been in this area.

In 2013, all the major browser providers started to phase out support for the underlying technology used by applets (primarily the NPAPI ). By 2017, it was impossible to run an applet in a modern browser. At the same time, Oracle announced, with the release of JDK 9, that applets were being deprecated . With the release of JDK 11, in 2018, the browser plugin was removed from the Oracle JDK.

Although the java.applet package is still part of the Java SE specification, all classes have been deprecated since JDK 9. The browser plugin and  appletviewer standalone tool are not part of the OpenJDK reference implementation so it is not possible to build these from open source.

For anyone who is still using applets in production, the only possibility for further updates would seem to be to purchase a Java SE Subscription from Oracle and continue using JDK 8. Unfortunately, even that is no longer a viable option, as it turns out that Oracle ended support for the browser plugin back in March this year. The answer then is to migrate to an alternative (most likely HTML, JavaScript, and CSS) as quickly as possible to avoid potential security vulnerabilities.

The sad news is then that applets are well and truly dead, they have ceased to be, they are no more. The good news, however, is that Java is still very much alive and well, and continues to be the most popular programming platform on the planet.

One quick thing: If you need a free version of the OpenJDK that's TCK tested and includes backports of features like TLS 1.3 and Flight Recorder, why not try Zulu Community ?

Further Reading

The Next Generation of Java Application Development

Java Getting Back to the Browser?

What Future Java Releases Mean for Legacy Desktop Apps