Java

Java on one screen: every building block, then and now

Java keeps old code running. Most classes written for Java 8 in 2014 still compile and run on JDK 27, so most code bases mix three or four eras, and most material online teaches the oldest one. Since a new release arrives every six months, a lot has been replaced. Here is all of it first. The table lists each job, the way current Java does it, the way it replaced, and the JDK release in which the current way became final — not preview, not incubator. It is also the fastest way to date a code base, a tutorial or a job candidate’s answer.

Releases, support, and which JDK you actually run

Since Java 10, in March 2018, a new JDK has shipped every March and September. Most releases are supported only until the next one, six months later. Every two years one release is designated LTSLTSLong-Term Support — a release patched for yearsA release line that keeps receiving security and critical fixes for a published period after newer versions ship, but no new features. It lets a team upgrade on its own schedule — until the end date on the support table, after which the next vulnerability has no fix at all.All terms — long-term support — and receives security fixes for years; since 17 the gap between LTS releases has been two years rather than three. The current LTS is 25, from September 2025; the latest release is 27, from September 2026; the next LTS will be 29, in September 2027. Production systems almost always run an LTS, and the features in the table reach most teams in LTS-sized jumps: 11, 17, 21, 25.

Those are Oracle’s dates for paying customers, and they are not the whole story. The JDK is one open-source code base, OpenJDK, and several vendors build, test and patch it: Eclipse Adoptium’s Temurin, Amazon Corretto, Azul Zulu, Microsoft and Red Hat among them. Their builds are the same code, their updates for each LTS are free, and each publishes its own end dates, usually several years past the release. Oracle JDK is one build among them, with a licence that has changed repeatedly since 2019: in April 2019 updates of Oracle JDK 8 stopped being free for production use; in 2021 Oracle JDK 17 came under a no-fee licence that ends a year after the next LTS ships; in January 2023 the paid subscription moved to a price per employee — every employee and contractor of the company, not per server or per developer; and from the October 2026 update, Oracle JDK 21 moves back under the licence that requires a subscription in production.

The machine underneath: bytecode, the JIT and warm-up

Java does not compile to machine code. The javac compiler turns source into bytecode — instructions for an abstract machine — and the JVM for each platform turns bytecode into something the processor runs. That indirection is why one JAR file runs unchanged on a developer’s Mac and on a Linux server, and it is where Java’s performance profile comes from.

The JVM starts by interpreting bytecode, which is slow, while counting how often each method runs. A method that crosses a threshold is compiled quickly by the first-tier JITJITJust-In-Time compilation — compiling while runningCompiling code while the program is already running: the runtime interprets it at first, watches which parts are hot, and turns those into machine code on the fly. That is why the first seconds after start are slower than the minutes that follow.All terms compiler, with counters left in to profile it. A method that stays hot is compiled again by the optimising compiler, which uses that profile: which branch is actually taken, which class really arrives at this call, which loop runs a million times. If an assumption later turns out wrong — a new subclass appears — the JVM throws the optimised code away and goes back a tier. This is why a Java service is noticeably slower for its first few thousand requests and then settles, and why its peak speed can beat code compiled ahead of time.

Start-up is the other cost: the JVM has to load, verify and link thousands of classes before it serves anything. That hardly matters for a service that runs for weeks and matters a great deal for a function that scales to zero. There are now four answers, each with a different price:

Memory: the heap, the collector, and the container around them

Objects live on the heap and are freed by a garbage collector, not by you, which removes the use-after-free and double-free bugs that dominate C and C++. Collectors rely on one strong observation: most objects die almost immediately. So the heap is split into generations. New objects go into a young generation that is collected often and cheaply; the few that survive are promoted to an old generation that is collected rarely and expensively. Long pauses come from the old generation, so "reduce garbage" usually means "stop promoting objects that should have died young".

The collector matters less, in practice, than the container around the JVM. Since JDK 10 the JVM reads the container’s memory limit rather than the host’s, and by default it takes a quarter of it for the heap: a 4 GB container gets a 1 GB heap, and most of the memory you pay for is never used. The common fix makes the opposite mistake. Setting the heap equal to the container limit — -Xmx4g in a 4 GB container — leaves no room for everything the JVM keeps outside the heap: class metadata, compiled code, a stack for every platform thread, network buffers, the collector’s own bookkeeping. The process outgrows the container, and the kernel kills it.

Spring: injection, auto-configuration and the proxy you do not see

Spring is close to universal on the Java server, and what it fundamentally provides is dependency injectionDIDependency Injection — dependencies handed in from outsideInstead of creating the objects it needs, a class receives them ready-made from outside. This is the thing that makes code testable: in a test you hand it a fake where production hands it the real database.All terms: a class declares what it needs in its constructor, and the container supplies it. That sounds like bureaucracy until you see the consequence — a class that receives its collaborators can be handed fakes in a test, so business logic is testable without a database, a network or a running server. Spring Boot adds auto-configuration, which looks at the libraries on the classpath and wires sensible defaults, and an embedded web server, so the application is one executable JAR. Boot 4.0, released in November 2025 on Spring Framework 7, requires Java 17 or later.

Spring Boot’s own support window is shorter than Java’s. Each minor line gets about a year of free fixes: 3.5 lost its free support on 30 June 2026, 4.0 keeps it until 31 December 2026, and 4.1, released in June 2026, until 31 July 2027. After that, fixes are commercial. A team that upgrades Java every two years and Spring Boot every two years is outside the free window for half of that time.

Threads, and what virtual threads changed

A Java thread has always been an operating-system thread. That gives real parallelism across cores — unlike PHP, Node.js or CPython, one Java process can keep every core busy — and it costs a stack of about a megabyte per thread, which is why servers keep threads in a pool. The classic Java web server assigns one thread per request, and its concurrency limit is the pool: Tomcat, embedded in Spring Boot, defaults to 200 threads. Two hundred requests in flight, however many of them are only waiting for a database.

Virtual threads, final in JDK 21, remove that ceiling. They are scheduled by the JVM onto a small number of operating-system threads, called carriers — by default one per core — and cost far less than a platform thread: a virtual thread’s stack lives on the heap and grows only as deep as it is used. When a virtual thread blocks on I/O, the JVM unmounts it: its stack is set aside on the heap and the carrier picks up another virtual thread. Ordinary blocking code, written in the plain style everyone knows, scales to hundreds of thousands of concurrent requests. In Spring Boot it is one property, spring.threads.virtual.enabled=true. That is why the reactive style, which bought the same scale at the price of a fully non-blocking chain and unreadable stack traces, is needed far less often than it was.

A virtual thread that cannot be unmounted is called pinned, and it keeps its carrier while it waits. On JDK 21 to 23 that happened whenever a thread blocked inside a synchronized block — common in older libraries — and with as many carriers as cores, a few pinned threads could stop an application, which is the fifth case below. JDK 24 fixed synchronized; a thread still pins while it is inside native code or a class initialiser. Switching virtual threads on changes more than the thread count, and most of the changes move the bottleneck rather than remove it:

Five cases, and what each one was missing

Each case below is documented in a vendor’s own advisory or roadmap, a government report, or the engineering write-up of the team it happened to. Three are security failures, one is a cost, and one is an outage — and in four of the five, what was missing was knowledge of what was actually running.

The second and third cases are the same failure four years apart. Apache Struts, a Java web framework, disclosed and fixed CVECVECommon Vulnerabilities and Exposures — a public ID for a known vulnerabilityA public identifier for a known security flaw, such as CVE-2021-44228 for Log4Shell, so that vendors, scanners and advisories all mean the same bug. The number says a flaw exists; how dangerous it is for you depends on whether you run the affected version and expose the affected part.All terms-2017-5638 on 7 March 2017. Equifax’s security team circulated the alert, but the system that ran Struts — the online portal where consumers disputed their credit records — was not patched, and the scan meant to catch it did not find it. Attackers entered on 13 May and stayed for 76 days; the data of about 147 million people was taken. The government reports that followed read as a list of missing inventory: the company could not reliably say which of its systems ran the library. In December 2021 Log4Shell asked every organisation the same question at once. Log4j 2, the most widely used Java logging library, evaluated ${jndi:ldap://…} lookups written inside the messages it logged, so any string an attacker could get logged — a username, a User-Agent header — made the server connect out to the attacker’s machine and, in many configurations, load and run code from it. It was rated 10 out of 10. Patching took four releases in three weeks, and the slow part everywhere was not patching but finding: Log4j usually arrived as a dependency of a dependency.

The fourth case is not a vulnerability, and it has cost some organisations more than one. Every change in Oracle’s licensing, listed in the releases section, arrived as an ordinary update to the same product. Organisations that had standardised on Oracle JDK because it was the default download could find, at an audit, that the updates they had been applying were licensed per employee across the whole company. Teams that had standardised on an OpenJDK build — the same code — noticed nothing. The control was the same one Equifax and Log4Shell were missing, applied to the runtime instead of a library: knowing what is actually running.

Where it degrades

Java’s real advantage on a long project is not speed. It is that the tooling assumes the code will outlive the people who wrote it: the build is reproducible, the dependency graph is explicit, refactoring across a million lines is mechanical and safe, and a production profiler, Flight Recorder, ships with the JDK at a cost low enough to leave on. When a Java system degrades, it is rarely the language. It is the runtime left on defaults nobody chose, an annotation trusted to do what it cannot see, or a dependency nobody knew was there:

• A heap equal to the container limit, which ends in an OOMKilled restart with no stack trace.
• A heap left at the default quarter, paying for memory the JVM never uses.
• Lazy JPA relations loaded in a loop, or in the view through open-in-view, turning one endpoint into hundreds of queries.
• A @Transactional method called from its own class, so the proxy is bypassed and nothing rolls back as designed.
• Virtual threads switched on with a connection pool of ten, which moves the queue rather than removing it.
• A reactive stack adopted for scale on Java 21 or later, where plain blocking code now reaches the same place.
• Exceptions caught and logged at every layer, so one failure produces five stack traces and no decision.
• An interface and a factory per class, for a second implementation that never arrives.
• Built-in serialisation accepting bytes from outside the process.
• A JDK or a Spring Boot line outside its support window — or an Oracle build nobody chose.

The honest limit is the runtime’s own shape. A JVM is built to start once and run for a long time, and every answer to fast start-up in the JVM section trades something away for it. A garbage collector, even one with sub-millisecond pauses, still means memory overhead and a process whose timing is not fully under your control. And the ceremony that pays back over a decade costs real time on a two-week prototype or a fifty-line script, where a lighter tool is simply the better choice.

The practical check is three commands against a running production instance. java -version gives the release and the vendor — the support table and the licence. jcmd <pid> VM.flags shows the collector and the heap the JVM actually chose. And the dependency tree from mvn dependency:tree or gradle dependencies, kept as an SBOMSBOMSoftware Bill of Materials — a list of what is insideA machine-readable inventory of every component a piece of software is built from, including the dependencies pulled in by other dependencies. It matters on the day a vulnerability is announced: without one, the question "are we affected?" is answered by guessing.All terms, is the answer you will need on the morning of the next Log4Shell.

When to use it

Related pages

• DevelopmentGoGo is a compiled language whose runtime runs thousands of cheap goroutines on a handful of operating-system threads, so code that blocks stays fast. That design is why a Go service reads top to bottom with no callbacks — and why its typical failure is not a slow request but a goroutine that waits forever. The page opens with every place a goroutine waits and what releases it, then covers the scheduler inside a container, goroutine lifetimes and leaks, shared memory and the race detector, errors, releases up to Go 1.27, memory and the garbage collector, five documented cases, and where it degrades.
• DevelopmentMicroservicesMicroservices are an architecture in which one system is built as a set of small services, each deployed on its own, owning its own data and owned by one team. Independent deployment is what the style buys, and every call that now crosses a network is what it costs. The page opens with sixteen problems the network adds and the pattern that answers each, then covers the nine characteristics the term was defined by, what you need before the second service, data across services, calls between services, running many of them, five documented failures, and where it degrades.
• DevelopmentAPI DesignAPI design is the work of deciding what other programs may send to yours, what comes back, and which of those promises you will keep for years. Anything a consumer can observe becomes part of the promise, and you cannot take it back alone. The page opens with sixteen decisions every HTTP API makes, the default to take and what changing each later costs, then covers what the contract includes, methods, status codes and errors, behaviour under retries and load, who may do what, changing a published API, five documented cases, and where it degrades.