Why 'Build Once, Run Anywhere' Is a False Promise – And Always Will Be

It has been nearly three decades since Sun Microsystems popularized the idea that developers could "build [software] once, run anywhere" (or "write once, run anywhere," as Sun put it).

And yet, despite steady interest in this concept, we remain far from a world where most applications can actually be written or built just once, then run anywhere. Most developers are still stuck dealing with the tedium of configuring and packaging applications to work under multiple environments because the "build once, run anywhere" dream has failed to come to fruition.

Sadly, I doubt it ever will. Let me explain by surveying the history of the "build once, run anywhere" concept, then discussing why it never really panned out.

History of an Idea: 'Build Once, Run Anywhere'

"Build once, run anywhere" refers to the idea that developers can write and/or package one version of their code, then deploy it anywhere, without having to worry about things like different operating systems, different browsers, different hardware devices, and so on.

As I've noted, this is a relatively old idea. It has its explicit origins in the mid-1990s, when Sun introduced the "write once, run anywhere" slogan as a way of promoting Java, a then-new programming language. One of Java's major selling points was that it was a cross-platform language that made it easy to write applications that could run on any mainstream operating system or hardware platform, thanks to Java's use of the Java Virtual Machine (JVM) to execute code.

Related:AI-Assisted Coding: What Software Developers Need to Know

Two decades later, in the mid-2010s, Docker promoted itself along similar lines as a platform that allowed developers to build code once and run it anywhere. This was a reasonable proposition because part of the value of Docker containers is that, at least in theory, a containerized application will run in the same way on any operating system and device that supports it, without being affected by most environment variables that exist outside the container.

coding-concept2

Why We Still Can't Build Once and Run Anywhere

To be sure, cross-platform languages such as Java and software packaging tools like Docker have made the lives of developers somewhat easier, in the sense that they do reduce the number of variables that programmers need to think about when writing and packaging software.

But it's still quite a stretch to say that anyone today can write or build their code once and run it anywhere.

JVMs might be able to run Java bytecode on any operating system, but only if the code itself is tweaked to work across operating systems. Variables like file paths and libraries — which different operating systems handle in different ways — mean that a Java app written for Windows may not work at all on Linux, for example.

Related:5 Ways Containers Benefit Developers

As for Docker, the build once, run anywhere promise always felt like hyperbole. Docker containers are OS-dependent; you can't run a Dockerized Windows app on Linux or vice versa. Plus, Docker doesn't even officially support platforms like Android.

On top of this, a variety of environment-specific variables, such as which container runtime and orchestration platform you use, could impact the way Docker containers run. The idea that a containerized app will always behave in the same way across any environment just isn't true.

Will We Ever Build Once and Run Anywhere?

I'm not writing this post to criticize the developers behind platforms like Java or Docker. Again, those tools do make the work of developers easier in many respects, even if they don't fully live up to the notion behind slogans like "build once, run anywhere."

My point instead is to emphasize that the very idea of removing all of the environment-specific variables and inconsistencies from software development just isn't realistic. Even today, when operating systems and browsers are far more standardized and similar than they were in the past, none but the simplest of apps can operate in the same way across disparate environments. It doesn't matter which language you use to write the app or how you package and deploy it; there is no way to make the environment variables irrelevant.

In this sense, the "build once, run anywhere" concept is kind of like NoOps: It's a nice idea, but it will probably never work in practice.