James Gosling and Java

Zusammenfassung

James Gosling designed Java at Sun Microsystems as a solution to two concrete problems: C++ code that crashed because of pointer errors, and programs that had to be recompiled for every target platform. Java’s garbage collector eliminated manual memory management. The Java Virtual Machine made the same bytecode run on any operating system. “Write Once, Run Anywhere” was not just a slogan — it was a response to the real pain of maintaining dozens of platform-specific builds. Java became the dominant server-side language of the enterprise internet era, the language of Android, and one of the most widely taught first programming languages in history. Whether Gosling approved of all these uses is a more complicated question.

Carnegie Mellon and the Desire for a Better C++

James Arthur Gosling was born on May 19, 1955, in Calgary, Alberta, Canada. He studied computer science at the University of Calgary (BSc 1977) and completed a PhD at Carnegie Mellon University in 1983, writing a dissertation on a WYSIWYG document formatter. During his PhD, he wrote a version of Emacs (GNU Emacs precursor), worked on multiprocessor systems, and developed a deep familiarity with the practical limitations of the tools he was using.

He joined Sun Microsystems in 1984. In 1991, he was assigned to a new research project: Green, aimed at building software for consumer electronics — set-top boxes, handheld devices, embedded controllers. The challenge was that consumer electronics manufacturers used wildly different processor architectures. A program compiled for one chip would not run on another. C and C++ required separate compilations for every target platform.

Oak → Java

Gosling designed a new language, initially called Oak (later renamed Java when it was discovered that Oak was already trademarked). Java’s design decisions were driven by the embedded systems context and by Gosling’s accumulated frustration with C++’s failure modes:

Automatic garbage collection eliminated the class of bugs caused by manual memory management — null pointer dereferences from freed memory, memory leaks, use-after-free errors. These bugs were endemic in C and C++ code; Java prevented them by design.

No pointers (in the C sense — direct memory addresses). Java had references, but they could not be manipulated arithmetically. Buffer overflows, the source of most security vulnerabilities in C programs, were impossible in Java.

The Java Virtual Machine (JVM). Rather than compiling Java source to native machine code, the Java compiler produced bytecode — an intermediate representation that the JVM interpreted. A program compiled once could run on any platform with a JVM: Windows, Solaris, Linux, Mac. The JVM abstracted the hardware.

Strong type safety. Java’s type system was stricter than C++’s and prevented entire categories of runtime errors at compile time.

// Java (1995) — write once, run anywhere
public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
    // No manual memory management
    // No pointer arithmetic
    // JVM handles platform differences
}

“Write Once, Run Anywhere”

The JVM made this possible in theory. In practice, the early Java implementations varied enough that programmers joked the slogan should be “Write Once, Debug Everywhere.” Library behavior, floating-point arithmetic, threading models, and GUI components all had platform-specific quirks that needed separate testing. The slogan was directionally accurate — Java programs required far less platform-specific work than C++ programs — but the ideal of perfect portability was not achieved until later JVM versions standardized behavior more rigorously.

The Internet Pivot

Sun released Java 1.0 in January 1996. The consumer electronics market that had motivated the project never materialized at scale — set-top boxes did not standardize on Java as Sun had hoped. But the World Wide Web was growing explosively, and Java found an unexpected home there.

Java applets ran in web browsers via a JVM plugin, adding interactive behavior to web pages before JavaScript was mature. The security model — each applet ran in a sandboxed JVM with restricted access to the underlying system — addressed the obvious concern about executing downloaded code. For a brief period in 1996-1998, Java applets were the dominant model for web interactivity.

Applets declined as browsers developed their own JavaScript capabilities and as the security model (constantly patched, never airtight) became a maintenance burden. But Java’s enterprise use grew in parallel: large organizations building server-side web applications found Java’s reliability, its extensive standard library, and its C-like syntax (familiar to their existing developer base) compelling.

Enterprise Java Beans (1997), Java Servlets and JSP (1997-1998), and the broader J2EE (Java 2 Platform, Enterprise Edition) framework made Java the default choice for large-scale enterprise web applications through the 2000s. SAP, IBM, Oracle, and most major enterprise software vendors built on Java.

Android and the Oracle Lawsuit

When Andy Rubin designed Android at Google, he chose Java as the programming language for Android applications — but not Oracle’s (Sun’s) JVM. He used a different runtime, Dalvik, that was incompatible with Sun’s JVM specification. Oracle, which had acquired Sun in 2010, sued Google in 2010 alleging infringement of Java API copyrights and patents.

The case — Oracle v. Google — was one of the most consequential software intellectual property cases in history. It reached the Supreme Court in 2021, which held 6-2 that Google’s use of Java APIs in Android was fair use. The decision avoided a ruling that would have allowed API copyright, which would have had enormous implications for software interoperability.

Gosling himself was critical of Oracle’s acquisition of Java and Sun’s technology portfolio. He wrote after leaving Oracle (which he did immediately after the acquisition): “During the integration meetings between Sun and Oracle where we were being grilled about the patent situation between Sun and Google, I was shown a document that had been prepared by some Sun lawyers. It was a rogue action by a senior lawyer… it made me ill.”

He joined Google in 2011, then Liquid Robotics (ocean robots), then Amazon Web Services in 2017, where he has worked on satellite and distributed systems.

Dead End: Java Applets and the Plugin Web

Java applets were the first major deployment of Java and the first technology to make web pages interactive. They failed completely.

The Plugin Model’s Structural Weakness

Java applets required a JVM browser plugin — a separate installation that needed its own updates, its own security patches, and its own compatibility testing with each new browser version. Each security vulnerability in the JVM became a browser vulnerability, since the JVM had elevated permissions relative to JavaScript. By 2010, the Java browser plugin was one of the most-exploited attack vectors in consumer computing. Apple refused to ship it on macOS starting in 2012; Chrome removed NPAPI plugin support in 2015. Java applets effectively ceased to exist as a technology. The failure demonstrated that rich-client browser applications required a technology integrated into the browser itself — which is what JavaScript became.

Java’s role in the OOP era is covered in The OOP Revolution. The Android context appears in The Mobile Computing Revolution.