How Java Is Used in Software Development in 2026, and What Needs Modernizing

The AI assistant gets built in a fortnight: a Python service, a hosted model and a TypeScript chat window. Then it has to look up a customer's balance or rebook a flight, and the systems that hold that data turn out to be Java 11 applications on Spring Boot 2, released twice a year because every deployment takes a weekend. That is how Java is used in software development at most established companies in 2026: rarely the language a new project starts in, and very often the language of the systems that project depends on. For their CTOs, the Java decision this year concerns bringing those systems up to current versions, so that new features, AI included, can reach them.

Java in 2026: a 30-year-old language on a six-month release cycle

Sun Microsystems released Java in 1995, so the language turned 30 last year. It has changed more in the past eight years than in the fifteen before them. Since Java 10 in 2018 a feature release has shipped every six months, and since Java 17 a long-term support (LTS) release has followed every two years.

The current LTS is Java 25, released in September 2025, and it is the version to target for anything going into production now. Two feature releases have followed it. JDK 26 (17 March 2026) added HTTP/3 to the built-in HTTP client, extended Project Leyden's ahead-of-time cache to every garbage collector, removed the Applet API and started warning when code uses deep reflection to change final fields. JDK 27 (15 September 2026) turns on compact object headers by default, makes G1 the default collector in every environment and adds post-quantum hybrid key exchange to TLS 1.3. Structured concurrency is still a preview, now in its seventh round.

Java's backward compatibility is unusually strong. Much of the bytecode compiled for Java 8 in 2014 still runs on JDK 25, as long as it avoids the few APIs removed since, such as JAXB, CORBA and the Security Manager. That is why Java systems last for decades, and also why so many of them are still on 8, 11 or 17.

What Java code looks like in 2026

A team that last wrote Java in the Java 8 era would find the language much less verbose. Records replace hand-written data classes, sealed types close a hierarchy, and pattern matching in switch lets the compiler check that every case is handled. This fee calculation compiles on Java 22 and later:

import java.math.BigDecimal;

sealed interface Payment permits Card, Transfer, Wallet {}

record Card(String pan, BigDecimal amount) implements Payment {}
record Transfer(String iban, BigDecimal amount, boolean instant) implements Payment {}
record Wallet(String provider, BigDecimal amount) implements Payment {}

final class Fees {
    private static final BigDecimal CARD_RATE = new BigDecimal("0.015");
    private static final BigDecimal WALLET_RATE = new BigDecimal("0.010");
    private static final BigDecimal INSTANT_FEE = new BigDecimal("0.20");

    // No default branch: the compiler checks that every permitted type is handled.
    static BigDecimal fee(Payment payment) {
        return switch (payment) {
            case Card(_, var amount) -> amount.multiply(CARD_RATE);
            case Transfer(_, _, var instant) when instant -> INSTANT_FEE;
            case Transfer(_, _, _) -> BigDecimal.ZERO;
            case Wallet(_, var amount) -> amount.multiply(WALLET_RATE);
        };
    }
}

Delete the Wallet case and the build fails, a check that earns its keep when part of the code comes from an AI assistant. For services that spend their time waiting on databases and other services, virtual threads (final since Java 21) let plain blocking code handle tens of thousands of concurrent requests without a reactive rewrite; the Java virtual threads guide covers the patterns and the pitfalls.

What does all this mean for Java?

Java is being modernized from the inside, in small compatible steps, with no breaking new version to migrate to. The OpenJDK projects behind the recent releases show the direction. Project Amber keeps cutting ceremony from the language, from records to pattern matching and compact source files. Project Loom made concurrency cheap with virtual threads and is finishing structured concurrency. Project Leyden goes after startup and warm-up time, the main cost of running Java in containers and functions. Project Panama connects Java to native code and hardware, with the Foreign Function and Memory API final since Java 22, and Project Valhalla is working on value classes that would give objects the compact memory layout of primitives.

The conclusion for a team running Java in production is practical: the platform is heading toward less code, lower memory use and faster startup, and each of those gains arrives only through an upgrade. A system that stays on Java 8 or 11 gets none of them. Our Java best practices guide shows which coding habits to keep and which Java 8 era advice to drop.

Where Java is used in software development today

Java's footprint in 2026 is concentrated on the server side of business systems: the services and systems of record behind the screens. The picture below is simplified, but it matches most of the systems we work on, from banks to travel platforms.

Enterprise back ends and APIs

Most Java written today is server code: REST and messaging APIs, batch jobs, workflow engines and the domain logic behind them. Spring Boot is the default framework, and Spring Boot 4 on Spring Framework 7 is the current generation. Jakarta EE 11 is the current specification for teams on application servers, while Quarkus and Micronaut serve teams that want faster startup and smaller containers. Netflix runs more than half of its critical streaming video services on JDK 21, and Amazon runs its Corretto JDK on thousands of production services; our Java applications examples collect the public cases.

Banking, payments and insurance

Finance is where Java is most entrenched. Core banking platforms, payment switches, trading and risk systems and insurance policy administration are full of it, because a system that will run for twenty years benefits from garbage collection, mature concurrency, static typing over money-handling code and a choice of runtime vendors. Low-latency trading teams use it too, with libraries such as the LMAX Disruptor, which came out of a London exchange.

Our longest engagement is an example. For Legerity we were the main development team on FastPost, a rule-driven accounting platform built in Java on in-memory data processing, which handles a billion financial transactions in under an hour in the cloud. The engagement ran for nearly ten years.

Travel and e-commerce

Flight schedule calculation, hotel availability, pricing and booking engines are a common Java workload: read-heavy, spiky and sensitive to latency. On a UK hotel metasearch engine we moved availability search from a cluster of SQL Server machines into an in-memory data grid. The Java system now answers 300 million queries a day, 50% more traffic than the system it replaced, at 80% lower infrastructure cost.

Big data and streaming infrastructure

Much of the data stack is JVM software even where nobody writes Java against it. Apache Kafka, Spark, Flink, Hadoop, Cassandra, Elasticsearch and OpenSearch all run on the JVM, so a data scientist calling Spark through PySpark is driving a JVM cluster. Teams that operate this infrastructure need JVM skills for heap sizing, garbage collection tuning and upgrades, whatever language their applications are written in.

Cloud services and serverless

Java's old weakness in the cloud was startup: a Spring application that takes several seconds to start is a poor fit for autoscaling and functions. GraalVM Native Image now compiles an application ahead of time into a native executable, AWS Lambda SnapStart restores Java functions from a snapshot, and CRaC checkpoints a warmed-up JVM on the builds that support it. Project Leyden's ahead-of-time cache, part of the JDK since Java 24, records class loading, linking and method profiles in a training run so later starts skip that work.

Android, where Java is now the legacy option

Java built Android, and a great deal of Android code is still Java. New work is not: Google has described Android development as Kotlin-first since 2019, and Jetpack Compose, its current UI toolkit, is Kotlin-only. Kotlin and Java interoperate in the same module, so a Java-era app can take new screens in Kotlin while the old ones stay as they are.

Where Java is rarely the first choice

Older lists of Java uses filled out with desktop GUIs, games and IoT. In 2026 those are niches. Browser front ends are TypeScript, games are mostly C++ and C# (Minecraft: Java Edition is the famous exception), embedded devices run C, C++ and increasingly Rust, and model training happens in Python. Swing and JavaFX desktop tools still run inside many companies, but few new ones are started.

Java popularity in 2026: what the rankings show

The rankings measure different things, and they agree on the trend. Java has lost the default position it held through the 2000s and 2010s, while staying in the top tier of languages professional software is written in.

The Stack Overflow Developer Survey 2025 asks developers which languages they used in the past year. 29.4% of all respondents named Java, seventh behind JavaScript, HTML/CSS, SQL, Python, Bash and TypeScript. In the 2021 survey Java was fifth with 35.35%, ahead of TypeScript at 30.19%; TypeScript has since reached 43.6%.

The TIOBE Index counts how much a language is searched for and written about, based on search engine results. It is not a usage count, but it shows long trends well. In September 2026 Java was fourth with 7.54%, behind Python (17.76%), C and C++. On TIOBE's twelve-month averages Java was first in 2006, 2011 and 2016, second in 2021 and fourth in 2026, while Python climbed from eighth to first.

GitHub's data shows where new code goes. According to Octoverse 2025, TypeScript became the most used language on GitHub in August 2025, with 2.64 million monthly contributors, up 66% in a year, while Python grew 48% on the back of AI projects. Java added about 175,000 contributors, a 20.7% rise that GitHub describes as "steady enterprise-driven growth".

Why new AI projects start in Python or TypeScript

The move toward Python and TypeScript is real, and AI speeds it up. The reasons are practical:

• Models are trained, fine-tuned and evaluated in Python. PyTorch, Hugging Face Transformers and vLLM are Python projects, and so is most research code.
• Model providers publish their SDKs, examples and agent frameworks for Python and TypeScript first; Java support tends to follow, often from the community.
• Front-end frameworks such as Next.js, Astro and SvelteKit generate TypeScript projects by default, so a product with a web front end and a thin back end can use one language from browser to API.
• A prototype that calls a model and prints the answer is a dozen lines of Python, which suits a team testing an idea in a week.

For a startup building an AI-native product, or a team training its own models, Python or TypeScript is usually the right place to start, and we would tell a client so. Most enterprise AI work looks different. The model is behind an API; the hard parts are retrieval over customer, policy or transaction data, permissions, audit trails and the transaction that follows the model's answer. Those live in the systems of record, and at most banks, insurers and travel companies the systems of record are Java.

Where Java fits in AI work

A Java team no longer needs a Python sidecar to call a model. Spring AI reached version 1.0 in May 2025, with a portable client for the major model providers, vector store integrations and tool calling, and LangChain4j covers similar ground outside Spring. In Azul's 2026 State of Java survey of more than 2,000 Java professionals, 62% of organizations said they use Java to code AI functionality, up from 50% a year earlier. Azul sells Java runtimes and support, so treat it as a vendor survey, but it matches what we see: AI features are being added to Java applications, and the applications stay.

The Octoverse report adds a point that applies to Java as well. GitHub ties part of TypeScript's rise to AI-assisted development, because a type checker catches the mistakes generated code makes before they reach production, and Java's compiler does that job on the back end. The condition is a codebase an AI assistant can work in: a current JDK, current frameworks and tests. A Java 8 monolith without a test suite is as hard for an AI tool to change safely as it is for a new hire. Our guide to AI application modernization covers that preparation.

Pros and cons of Java in 2026

The table weighs Java as it stands in 2026. Several classic complaints, verbosity and slow startup above all, have shrunk since the old comparisons were written; memory footprint and dependency sprawl still cost real money.

Memory is the weakness that shows on the cloud bill. In the same Azul survey, 74% of organizations reported more than 20% unused compute capacity in their public cloud, which Azul reads as overprovisioning to cover slow startup and warm-up. The fixes are rarely a change of language: right-sized heaps and containers, a current collector, and compact object headers, a product option since JDK 25 and the default in JDK 27. The guide to improving Java performance goes through the rest.

Why so much business-critical Java needs modernizing

The systems that make Java matter in 2026 are mostly not new. A ledger, booking engine or claims platform built in 2012 has been extended every year since, and its foundations were often upgraded only when something forced it. These are the gaps we find again and again when we assess one:

• An old JDK: Java 8 or 11 in production, sometimes an Oracle build whose licence nobody has checked.
• An old framework: Spring Boot 2.x or Spring 5 on the javax namespace, or an application server from the same era.
• Dependencies nobody tracks: libraries abandoned by their authors, with known vulnerabilities and no release for current Spring.
• One large deployable, where a one-line change needs a full regression cycle and a release window.

A system in this state can run for years without an incident. The cost appears when the business needs it to change quickly: a new payment rail, an API for an AI assistant, an audit finding with a deadline.

The support deadlines behind the drift

The calendar now sets the pace. Every Spring Boot 3.x branch left open-source support on 30 June 2026, and 4.0 follows in December 2026 (the Spring Boot 4 migration guide has the dates and the upgrade path). From the October 2026 update, Oracle JDK 21 patches need a paid subscription in production, and four Java LTS releases lose Oracle's extended support between September 2029 (Java 17) and January 2032 (Java 11), with Java 8 in December 2030 (see Java end-of-life dates).

The JDK is also closing old doors. The Security Manager has been permanently disabled since JDK 24 (JEP 486), and JDK 26 removed the Applet API. JDK 26 also warns when a library uses deep reflection to change a final field, a first step toward making that an error; older serialization and dependency injection code is where those warnings tend to appear.

What a modernized Java system looks like

Modernization has a concrete target. The table compares a typical system built in the mid-2010s with where it should be in 2026. Most systems need some of the rows, rarely all of them.

Upgrading in steps instead of rewriting

The tempting answer to an old Java system is a rewrite, often in whatever language the newest team prefers. For a system that holds fifteen years of business rules, that is usually the most expensive and riskiest option, because the rules have to be rediscovered from the code while the old system keeps changing. Upgrading in verifiable steps keeps the system running and shipping throughout.

That is how we approached the online store and back office of a London wine merchant: one Java codebase built up over fifteen years, on Java 17 and Spring 5, with 12 critical and 35 high-severity advisories in its dependencies. We added regression tests around the flows the business relies on, moved more than 800 files to the Jakarta namespaces by automated refactoring, upgraded to Spring 6.2 and Hibernate 6.6, and finally moved the build and runtime to Java 25. The core upgrade took about four weeks with no feature freeze, and the advisories went from 47 to zero.

Where the architecture is the problem, the strangler pattern applies the same idea at a larger scale: one capability at a time moves to a new service while the monolith keeps the rest. The legacy system modernization guide covers the wider set of options.

Java's share of new projects will probably keep falling, and for a company whose revenue runs through Java systems that matters less than the headlines suggest. Those systems are worth keeping and bringing up to date, with Java 25, Spring Boot 4, tests, and APIs that AI features can call. Our application modernization work starts with a written inventory of what runs where, the upgrade order and a ballpark estimate. If your systems are still on Java 8 or 11, or on Spring Boot 2, a scoping call is the quickest way to find out what the upgrade involves.