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.
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 colour 3D molecule image in the browser, clicked on it, and rotated the molecule back and forth. The entire audience, who had not really being paying much attention up to 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 fixing the .java_wrapper (remember that?) it turns out the libc is 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 screen shots. (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, that first Eureka demonstration did not lead to a situation today where all web-based applications use Java. In fact, 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, 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 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.
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?
