The story of Java backend.

Why we start with history

Most courses throw you into Spring Boot on day one. You learn an annotation, you copy a snippet, it works. Magic. Until something breaks. Then you have no idea why.

The reason most learners feel lost in Spring Boot is they meet the solution before they ever met the problem. Without the problem, the solution feels arbitrary.

So today we walk through the problems first — in order. Each problem produces a solution. Each solution creates new problems. That is the entire history of Java backend in one sentence.

1970sPrograms lived on one machine

Picture a developer in 1975. There is no internet. No browsers. No "websites." A program ran on a single mainframe — a refrigerator-sized computer. Users connected through dumb terminals (just keyboards and screens with no brain of their own).

The dominant language was C. Every database came with its own C library. There was no concept of "the network." Everything was on one machine.

1980sC++ and the rise of OOP

C++ arrived. It added classes, inheritance, polymorphism — what we call Object-Oriented Programming. OOP was a way to organize bigger codebases without losing your mind.

C++ became the language of operating systems, compilers, and games — anything needing both performance and structure. But programs still lived on one machine. C++ was not used for "web development" because the web didn't exist yet for normal people.

1991–93The internet becomes public

Three things happened almost together: Tim Berners-Lee invents the World Wide Web at CERN (1989–91), the Mosaic browser launches (1993), and Internet Explorer + Netscape turn the web into a household thing by the mid-90s.

Suddenly, machines need to talk to each other over a network. This is a totally new problem that no language at the time was designed to solve cleanly.

How early websites worked

A browser asks for a page. A web server returns an HTML file (just text on disk). That's it. Static. Every visitor saw the same page. But people quickly wanted dynamic pages: "show me today's news", "log me in". How?

CGI scripts — the first "backend"

The first solution was called CGI (Common Gateway Interface). When a browser request came in, the web server would:

1. Spawn a fresh process (start a new program from scratch)
2. Run a script (usually Perl, sometimes C)
3. Capture whatever the script printed
4. Send that output back to the browser

This worked. It was the first time the web had dynamic pages. But it was painfully slow. Spawning an OS process per request is expensive. If 1000 users hit the site at once, the server collapsed.

1995Java is born

Sun Microsystems releases Java with a marketing slogan: "Write Once, Run Anywhere." Compile your code once → it runs on Windows, Mac, Linux — without changes.

How? Java doesn't compile to machine code (the way C/C++ does). It compiles to bytecode — an intermediate language. Any computer with the JVM (Java Virtual Machine) installed can run that bytecode. The JVM translates it into the right instructions for whatever OS it's on.

Java came in three flavors:

But here is a critical fact most learners miss: Java alone could not handle HTTP. Java had no built-in way to receive an HTTP request, parse it, and return an HTTP response. The language was great, but it was deaf and dumb to the web. Something had to bridge Java and HTTP.

Applets — Java's failed first try

Sun's first idea was to put Java inside the browser. Tiny Java programs called Applets ran via a JVM plugin. It failed: slow, security concerns, browsers killed plugins. Philosophically — business logic should run on a server you control. Sun pivoted: Java would run on the server. This pivot gave us Servlets.

~1997Servlets — Java's first real backend

A Servlet is a Java class that handles an HTTP request. But a Servlet alone does nothing — it needs a runtime called a Servlet Container. The most famous one is Apache Tomcat.

CGI vs Servlets — the key shift

What the Servlet container does NOT do

You asked the perfect question: where does JSON → object conversion happen? In Spring Boot, @RequestBody magically converts JSON to a DTO. In Servlets — that magic doesn't exist. You write it yourself.

// Read the raw body bytes
String body = req.getReader().lines().collect(Collectors.joining());

// Manually call Jackson
ObjectMapper mapper = new ObjectMapper();
UserDto user = mapper.readValue(body, UserDto.class);

// Manually validate
if (user.getEmail() == null) { /* return 400 */ }
// ... then call your service ...

The Servlet pain — and the layers we still use today

Imagine a registration form with 10 fields. In a raw Servlet, you'd extract each parameter, validate each, open a database connection, write SQL, close it, print HTML — all in one method. Horrible.

Developers in the early 2000s split this into layers:

JSP — escaping "HTML inside Java"

Writing HTML inside Java with out.println() was awful. Sun invented JSP (Java Server Pages): HTML files with embedded Java snippets. The Servlet container compiled JSP files into Servlets behind the scenes. JSP is mostly dead today — replaced by REST APIs returning JSON, with React/Vue/Angular handling HTML on the client. We won't write any JSP. You only need to know it existed.

2003Spring is born

By the early 2000s, Java enterprise apps had become a mess: heavy EJBs (Enterprise Java Beans) needing expensive application servers, hundreds of XML files, and tightly-coupled code (every class created its own dependencies with new, making testing nearly impossible).

A developer named Rod Johnson wrote a book in 2002 showing a lighter way. The ideas became the Spring Framework.

Spring's two killer ideas

class A {
  B b = new B();
  // A controls how B is built
  // can't swap B for a fake
  // in tests
}

class A {
  B b;
  A(B b) { this.b = b; }
  // B is given to A
  // can swap easily
  // can test in isolation
}

2014Spring Boot

Spring Boot solved Spring's setup pain with two ideas:

Idea 1 · Convention over configuration

Sensible defaults everywhere. You only override what's truly different about your app.

Idea 2 · Embedded server

In the old world, you wrote a .war file then deployed it into a separately-installed Tomcat. Spring Boot ships Tomcat inside your JAR:

$ java -jar myapp.jar

…and your web app is running. No external Tomcat. No web.xml. This is the world we live in today.

todayThe modern Java backend stack

The full story in one frame

What this means going forward

End of Day 1. Close the document. Let it sit overnight. The mental skeleton you just built will pay back every day for the next 8 weeks.