The Story of Java: From 1991 to Today

Java began at Sun Microsystems in **1991** as a project called **Oak**, led by **James Gosling** with Mike Sheridan and Patrick Naughton. The stated goal was software for consumer electronics, specifically set-top boxes for interactive television, plus handheld remotes and other embedded appliances.

The problem it was meant to solve was real. These devices shipped with different processors, and the industry assumption was that software would migrate between them. Writing in C or C++ meant recompiling for each target, and for anything touching the operating system, rewriting the platform-specific code.

THE PROBLEM AS IT LOOKED IN 1991
   ┌───────────────────────────────┬───────────────────────────────┐
   │ Devices used different CPUs    │ Native binaries do not travel │
   ├───────────────────────────────┼───────────────────────────────┤
   │ Set-top boxes, remotes,       │ Recompile for every target,   │
   │ printers, anything embedded   │ and rewrite the OS-specific   │
   │                               │ parts entirely                │
   └───────────────────────────────┴───────────────────────────────┘

The solution was to put a virtual machine between the source and the hardware, so that the platform-specific layer is written once per device rather than once per application.

The consumer electronics market did not materialise as expected, and the original business case for Oak largely collapsed. What saved the project was a different distribution channel: the World Wide Web.

Java's first release was **Java 1.0 on 1996-01-23**, and it shipped with class file version **45.0**. The name had already been changed from Oak to Java by this point, in 1995.

The reason the Web turned out to be the perfect host for the language is the same reason the project had been designed for embedded devices: the Web spans heterogeneous hardware, and Java's portability meant a program could run on whatever machine the visitor happened to have.

The early story is usually told as applets in browsers, and it is worth being precise about what that did and did not achieve. Applets did drive enormous public and developer interest, but the durable enterprise adoption of Java came later, through servers. Applets themselves are gone from the platform: java.applet.Applet was deprecated for removal in Java 17 and the Applet API was finally removed in Java 26.

**Java 1.2 arrived on 1998-12-04** with codename *Playground* and class file version **46.0**, and it is the release usually treated as the real beginning of Java as a mainstream language. It added the Collections Framework, Swing, strictfp, and the Sun JIT compiler.

The big institutional story of this era is enterprise Java. J2EE, later renamed Java EE, packaged the platform for server-side development, and the Servlet, JDBC, and RMI APIs became the backbone of a large amount of business software. This is when Java became primarily an enterprise language, and it is the origin of much of the ecosystem still in use today.

Between 1.2 and 5 the releases were named after animals and birds, such as *Kestrel* and *Tiger*, which is usually remembered with affection and sometimes with relief.

**Java 5 on 2004-09-30** is arguably the most important single release in the language's history, because it is the point where Java stopped looking like an awkward C++ derivative. It added generics, annotations, enums, autoboxing, the enhanced for loop, varargs, and static imports.

// Java 5 generics: type safety without casting
List names = new ArrayList();
names.add("alpha");
// Java 5 enums
enum Status {
    NEW, RUNNING, DONE
}// Java 5 autoboxing, no explicit new Integer(...)
Integer count = 1;

The effect was that Java 5 code is recognisably modern Java. The gap between the 1.x style and the 5 style is the largest stylistic break in the language's history.

Oracle completed its acquisition of Sun Microsystems in **January 2010**. The deal guaranteed the continued funding of the Java platform and in particular the HotSpot JVM, and under Oracle the language moved onto a predictable release schedule rather than the long, irregular gaps that had characterised the previous decade.

There was also sustained community concern during this period, mostly about licensing changes to Oracle's JDK builds. The practical response was OpenJDK, which became the reference implementation, and today the major distributions such as Temurin, Corretto, and Zulu all build from it. In practice, almost all Java in production today runs on OpenJDK code, regardless of vendor.

**Java 7** brought the diamond operator and try-with-resources, which quietly removed a large amount of noisy code.

**Java 8 on 2014-03-18** was the first LTS release under the modern world, with class file version **52.0**, and it is the most consequential release since Java 5. Lambda expressions, method references, the Stream API, java.time, and default methods all arrived at once.

List.of("alpha", "beta", "gamma").stream() .filter(s -> s.length() > 4) .map(String::toUpperCase) .forEach(System.out::println);

Java 8 also started the long support story that matters operationally. It is EOL in 2027, which makes it the oldest currently supported LTS and unusually long-lived for a release line.

In **September 2017** JDK 9 shipped, introducing the module system, jshell, and JEP 280 string concatenation. More importantly for planning purposes, it inaugurated the six-month feature release cadence that still governs Java today, with a feature release every March and September and a long-term support release roughly every two years.

The practical effect is that Java development is now incremental rather than event-driven. A feature you read about has a known minimum version, and an LTS gives a multi-year support window.

RELEASE TRAIN
   ┌──────────────────────────────────────────────────────────────┐
   │  every 6 months:  9, 10, 11, 12, ... 26, 27   (features)    │
   │  every ~2 years:  8, 11, 17, 21, 25          (LTS + support) │
   └──────────────────────────────────────────────────────────────┘

This matters more than any single feature, so it is worth getting exactly right. The current support picture, as of late 2026:

**Java 25 is the current LTS** and **Java 27** is the current feature release. Java 8, 11, and 17 all reach end of support in 2027, which is a real planning deadline for anyone still on them.

The class file version is worth noticing, because it is the mechanism behind backward compatibility. Each release increments it, and a newer JVM can always run older bytecode.

Rather than every release, these are the ones that change how you write code.

Text blocks are a good example of what a "final" feature looks like in practice, and they arrived in 15:

String query = """
        SELECT id, name
        FROM customers
        WHERE active = true""";

It is easy to read "virtual threads, Java 21" and assume the concurrency story was completed there. It was not. **Structured Concurrency has been repeatedly previewed and never finalized**, and it is the clearest illustration of how the JDK process actually works.

JEP 428 Java 19 incubating API JEP 437 Java 20 second incubator JEP 453 Java 21 first preview JEP 462 Java 22 second preview JEP 480 Java 23 third preview JEP 499 Java 24 fourth preview JEP 505 Java 25 fifth preview JEP 525 Java 26 sixth preview JEP 533 Java 27 seventh preview

The reason it keeps changing is that structured concurrency is genuinely hard to get right, since a wrong API here becomes permanent and hard to remove. Virtual threads, by contrast, *are* final in Java 21.

The lesson is worth stating plainly: a feature listed for a release may still be a preview in that release, so always check whether something is final before designing around it.

The single most consequential thing about Java's history is not any feature, it is that **old bytecode keeps running**. Code written for Java 1.0-era syntax still compiles and runs on a Java 25 JVM, which is why a long-lived enterprise system can be upgraded in JDK steps rather than rewritten.

The example accompanying this topic demonstrates exactly that, mixing 1996-era array-and-StringBuilder code, 2004 generics, 2014 streams, and 2021 records in a single class that compiles and runs unchanged.

// all of this compiles together on a modern JDK
String[] classic = {
    "one", "two"
};
// 1996 style
List names = new ArrayList();
// Java 5
Stream.of("a").filter(s -> s.length() > 0) // Java 8
.forEach(System.out::println);
record Release(String what, int since) {
} // Java 16

This compatibility is also a constraint, not just a benefit. It is why Object.finalize() could be deprecated in 9 but survived for years, and why removals like the Applet API took from deprecation in 17 all the way to removal in 26.

Applet API: deprecated for removal Java 17(JEP 398)↓removed Java 26(JEP 504) SecurityManager: deprecated for removal Java 17(JEP 411)↓not yet removed, but unusable in practice

Three lessons carry forward from this timeline. First, Java's most valuable property was never any individual feature; it is the combination of static typing, memory safety, and backward compatibility, which together make it viable for systems measured in decades. Second, the release process is now predictable enough that version numbers are part of everyday planning, so you should always target an LTS and know when it expires. Third, "shipped in version X" does not mean "final", and the structured-concurrency record of eight iterations since 19 is the clearest proof.