HotJava

You can’t talk about Java applets without giving the whole “origins of the web” spiel, so here goes:

Back in the neolithic era (10 000 BC to 2 000 BC), the web consisted only of static websites; plain HTML pages, CSS wasn’t even out yet. There was a desire to create interactive applications that are distributed through the web, but there was an issue: the web was inherently heterogeneous. Different web users were using different web browsers on different operating systems on different computers running different CPU architectures. It would be infeasible to publish separate native binaries to support each system and even if it was possible you wouldn’t want to because running arbitrary code from the internet straight on your machine is generally a poor security practice.

Around this time, Sun Microsystems was working on a similar issue with embedded systems. They developed Oak, later named Java, as a middleware between the hardware and firmware of an embedded platform and the program code of an application. Java was special because it used a virtual machine. This meant that Java code was not compiled for the architecture you were working with but rather an intermediate Java bytecode that was usable anywhere a Java runtime was available. Sun called this “write once, run anywhere”. It didn’t take Sun long to realize how Java could solve the web interactivity problem and pivot most of Java’s effort to the burgeoning platform.

This is where most web history summaries stop or change subject but I want to take some time to give you more perspective on what Java was doing from the late 90s into the 2000s. Java had gone all in on network computing. As Sun said: the network is the computer. Java loads its classes using a ClassLoader, which is a Java object, and can procure the class data however it pleases. By default, Java uses a URLClassLoader, which can load classes from any location accessible using the protocols supported by URL, which you can of course add to. In the base runtime, URL is guaranteed to support HTTP, FTP, and file protocols, meaning right out of the box Java could run code loaded directly from a remote server.

The concept of embedding Java into other applications as a sort of scripting language was everywhere too. Just look at the ill-fated VRML, a markup language for 3D virtual environments, which supported interactivity by loading Java code with access to the VRML document. This was a period where Java was everywhere, doing everything. It ran your cable box and your smartphone and desktop applications and web applications and web servers and it was on 3 billion devices.

From its first releases, Java has supported applets; Java applications embedded into websites. They predate Netscape’s plugin api (NPAPI), instead browser vendors where expected to come up with their own JVM implementation compliant with the Java Virtual Machine Specification and embed that into their browser directly. The first browser to support applets was HotJava, a browser made entirely in Java whose creation significantly influenced Java itself. Following the release of NPAPI, the most popular way to run Java in the browser was using the Java plugin. You could now run interactive Java application on any browser on any operating system on any computer on any CPU architecture. And Stanley was happy.

Embrace Extend Extinguish

This was the attitude and mantra of Microsoft for many years: embrace a standard, extends the standard with proprietary extensions, extinguish standard compliant implementations as users become dependent on Microsoft extensions. Indeed Microsoft attempted to do this with the web and Internet Explorer, even going to far as to include a non-compliant JVM implementation (and getting them sued by Sun). Their efforts ultimately failed due in part to the IE browser engine just not being very good and being surpassed by the more standards focused Gecko and later WebKit.

It seemed the days of the browser wars and proprietary extensions to the web in a bid to eliminate competition and establish a monopoly were over, but there’s nothing Microsoft can do that Google isn’t convinced it can do better. Throughout the 2010s, Google extended Javascript beyond web standards in the hope to push more websites into relying heavily on Javascript for their site to function. Thus started the era of the Chrome Experiment, Javascript based web demos created to push new users to adopt Google Chrome. Google’s reason for doing this: their Javascript runtime V8 which ran much faster than other browsers. Pages heavily laden with poorly optimized Javascript, such as Google’s own offerings, could run smoothly on Chrome while running poorly or not at all on competitor’s browsers. Conveniently, this gave Google plausible deniability in the unlikely event the DOJ rose from the grave and brought antitrust charges against them: they could simply claim that they’re much better at writing Javascript engines than they are at writing Javascript.

Mozilla would quickly catch up but by that point the damage was done, Chrome held the vast majority of the browser market share. It was around this time that people — regular people and not security researchers — started talking about Flash Player zero days, and Google began their campaign against browser plugins. Google was promoting their own browser extensions, they were written in Javascript, they were much more restrictive, and importantly for Google, they were distributed through the Google Web Store which they controlled.

Google had a point though, plugins suffered issues in security, reliability, and platform support. Being third party dlls injected straight into the browser’s address space, they completely bypassed any security or sandboxing the browser might try to implement, they have the potential to clobber browser memory causing hangs or crashes, and being that they were native executables, they exhibited the platform support problem that Java was supposed to solve. By this point in time, most of Chrome’s experimental extensions where now standard and, combined with HTML 5, covered the majority of use cases that applications designed for these plugins had been used for. Ultimately, every major browser dropped support for NPAPI plugins the moment they thought they could get away with it.

Our $0 Question: Why Bother?

So if NPAPI plugins stink on ice, and Javascript does everything they did but better, then why bother writing a Java applet in the year 2025? For the same reason I have Counter Strike installed on my cell phone: It’s really funny. There’s certainly a lot to be said about the Java ecosystem and writing in a statically typed language but fundamentally I just think it’s a funny way to make video games. It’s the same reason I ever use Greenfoot or Scratch, both educational tools that use video games to introduce children to coding concepts and suffer as a game creation tool as a result.

Java applets are a poor medium to make video games. They have no 3D acceleration. You have to write your own game loop and pry input events from Swing by any means necessary. Even just getting an applet to load in the browser is pulling teeth. All of these issues do not deter me, and are in fact the entire reason I’m even doing this in the first place.

Apply Video Game Directly to Forehead

If I write a game using a deprecated technology that hasn’t been supported by browsers in nearly 10 years, then how can I expect anyone to play my game? It’s simple—in the way that nuclear physics or the Apollo missions are simple, which is to say that it’s actually really complicated— by the same means that saw Java leave the browser in the first place: Javascript has gotten really good. Javascript and WebAssembly are now so sophisticated and run so fast, you could probably run a full-fat JVM in the Javascript environment. In fact you can, and someone has.

A company called Learning Technologies has created a tool called CheerpJ, a full JVM that runs in the browser like it’s 1996 again. The performance also reminds me of 1996, but what can you expect given the layers it has to go through. The fact it works at all is astounding.

What is this?

It’s Microsoft Excel

On visiting the page for this experiment, you will be able to play the Java applet in your browser using either your browser’s native Java support (which it probably doesn’t have) or using CheerpJ. Right now it’s a bit barren. All you can do is play a fairly primitive Breakout clone, missing powerups, sounds, and even scoring, but with what is probably the most robust collision system of any breakout clone you’ve played. It’s not really a full game, just a tech demo.

Things to do

I do hope to make an actual game using this technology at some point. Maybe something multiplayer, using websockets and marshaling JavaBeans through the pipes with my own home-spun protocol. Life could be dream. In the meantime, I hope to continue work on this demo, adding features and technologies like sound and if I’m feeling especially ambitious I might try my hand at 3D support using different backends for different platforms (webgl on CheerpJ for instance).

I intend to make more of these long rambling screeds as well, so be warned. I had intended to go into much more detail on the technical workings of the Java based game engine I’ve built for this project but given how much space it has taken just to explain what I’m doing and why, I’ve decided to leave the specifics of how for another post.

On open source, I do hope to release the source code for this. There’s really no reason not to do it now beyond the fact of it being a bit of a mess at the moment. I’m still deciding on a license. My go to is the AGPL but I think that’s a but much to ask of people who want to use it. LGPL seems the obvious choice at it would allow users to keep the code for their game closed source while modification to the engine need to be shared with the community. Alternatively, most the free assets on itch use CC0, so that or the unlicense is definitely a tempting choice.