How Java became irrelevant

Why I no longer use Java for backend services

I spent 18 years of my career advocating and using Java for all of my projects. However, in the past six years, my use of Java has dropped to practically zero.

Each new programming language and platform is meant to solve a particular set of problems. The prolonged use of tools that no longer solve relevant problems makes solving contemporary issues harder. When Java first came out in 1995, it set out to solve specific problems that are no longer relevant 27 years later.

Platform independence in 1995 was strategically crucial to any company trying to compete with Microsoft, whose Windows operating system was dominant. By convincing developers to use a toolchain that could produce executable artifacts that could be distributed to many platforms, competing operating systems could gain new applications.

The way Java achieved platform independence was by using the concept of byte-code. The Java compiler never produced the final binary executable for any particular hardware and operating system combination. Instead, it produced byte-code, a higher-level binary code than machine code. This byte-code would then execute in a Java Virtual Machine (JVM) in its final deployment environment. The JVM, in turn, would dynamically translate byte-code into native code at runtime.

The JVM itself had to be installed on the operating system to run Java applications. Initially, all major operating systems enthusiastically embraced it. In theory, if all new applications were built in Java, all operating systems that could run a JVM would automatically be able to run them.

Sun Microsystems (the original company behind Java) built out what they called Abstract Windowing Toolkit (AWT) and later Swing to support platform-independent user interfaces. They built abstractions over most common UI artifacts such as lists, buttons, windows, frames, tabs, dialogs, and pop-ups.

The cracks in the Java-on-the-desktop idea began to form early on. The problem was that Java prevented developers from taking advantage of native operating system capabilities by abstracting GUI artifacts. Desktop Java applications would never look as polished as native, and they would never perform as well either.

Microsoft built their proprietary JVM. When Apple launched macOS X, they initially included support for Java as one of the primary languages and runtime environments for MacOS X applications. Though AWT was part of the JVMs, by promoting their native UI frameworks, both Apple and Microsoft sabotaged the idea of a platform-independent UI.

The growth of Java on the desktop was therefore stunted from the beginning. Today, except for a few niche products such as Integrated Development Environments (IDEs) and legacy enterprise applications still eking out their daily survival, Java on the desktop is effectively dead. IDEs, by their very nature, must be platform-independent and allow developers to use whatever development environment they find appropriate for their productivity. Enterprise desktop applications written in Java could be implemented as full-stack, at least theoretically. 

Over time, the mistakes made by Oracle, legal battles over JVM distribution, security incidents, and the rise of smartphones and modern web browsers destroyed the idea that platform-independent UIs can be built in Java. As of today, the only user-facing platform still running Java natively is Android, and platform independence means running Java apps on various Android devices — if such a thing is even possible.

Java’s prospects on the servers looked much better. Platform independent networking, concurrency, and distributed computing capabilities proved valuable. As is typical in most situations, a developer could write and test backend code in a platform-independent manner on their computer. They could then deploy their work to the server, which could be a UNIX server. 

Typically a Java server would run a JEE (Java Enterprise Edition) application server. A single application server would run multiple applications at a time. The application components would take the form of servlets and Enterprise Java Beans. The application itself would be packaged as an Enterprise Application Archive (EAR) and deployed to the application server utilizing its command line. It made sense in the late 1990s and the first decade of the 2000s when there was no such thing as a public cloud, on-premise servers were expensive shared resources, and application server licenses were sold by CPU.

JEE application servers were expensive, bloated, and resource-intensive. They also had proprietary features. Rather than being tied to an operating system, Java server components would get linked to an application server. One of the projects I worked on was porting a trading system backend out of WebLogic to run as a simple Java process.

The rise of containers such as Docker put an end to the idea that JVM was the only way to run platform-independent backend code. One of the problems with JVM was that over time, different versions of JVMs became incompatible with one another. So, developers used Docker to control the version of JVM. However, Docker itself raised some questions about the need for the use of Java and JVM at all — if I can run Docker on my development machine, use whatever language I want, and then deploy this Docker container on the server, why do I need a JVM at all?

The decline of on-premise servers and the rise of server-less public cloud put the final nail in the coffin of JEE application servers. If I can deploy my docker containers in the form of AWS Lambda functions or AWS ECS services, I need neither Java nor JEE servers. I can pick whatever language works best for my productivity and my application’s performance. I can write my code once, build a container, and deploy it anywhere I want.

Platform independence was not the only problem Java solved. Java addressed many of the complexities of C and C++. Java streamlined object-oriented programming. Though relevant in 1995 and the first decade of the 2000s, today very few applications have more than 2 levels of class hierarchy and modern languages like Swift, Go, and Rust address complexities of C, C++, and now Java in much better ways.

Final thoughts

Though Java was my primary way of earning a living from about 1997 to 2015, it has long outlived the problems it solved. Java’s issues are being solved now by modern tools like Docker. Except for a few niche use cases, I no longer use Java for my projects.