Is Java still used in 2026? Usage data and a verdict

What the usage data says

Java ranked fourth on the TIOBE Index in October 2026 with an 8.41% rating, behind Python at 19.23% (TIOBE Index, October 2026). In the 2025 Stack Overflow Developer Survey, 29.4% of respondents reported working with Java in the past year, seventh among programming, scripting and markup languages (Stack Overflow Developer Survey 2025).

Neither figure is a market share. TIOBE is built from search engine results for each language, and the survey counts developers who used it. Both put Java in the top tier, and production banking, enterprise backend and Android workloads still run on it. Java 17, 21 and 25 are the LTS releases in active use, and Java 8 is what holds older estates back.

For enterprise and scale-up clients, Netguru designs and builds Java and Kotlin backends, Android apps and cloud-native platforms. We recommend Java for long-lived backends and existing Android codebases, because the hiring pool and LTS support runway lower delivery risk.

The verdict shifts for short-lived data or ML work, where Python fits better, and for estates still on Java 8, where upgrade cost drives the decision.

Where is Java used today?

Java is used today in enterprise backends, fintech, big data, cloud-native services, and Android, and its standing differs in each: default in some, contender in one, legacy holdover in another. Spring Boot, Apache Kafka, and Apache Spark carry most of that footprint, while Kotlin-first Android development has taken over new mobile work.

The map below is our judgement of each workload. The last column names the signal that would change it.

Workload	Java's standing	Why	What would change our view
Enterprise backends	Default	Spring Boot, mature libraries, and a deep pool of experienced developers	Your organization standardizes new services on Kotlin or Go
Fintech and banking	Default	Long-lived core systems, JVM tuning and observability tooling	A funded, scheduled replacement of the core ledger
Big data	Default	Kafka and Spark run on the JVM and expose Java APIs	Your pipelines move to a managed engine where nobody tunes the JVM
Cloud-native microservices	Contender	Virtual threads and native image narrow the gap with Go and Node.js	Your own startup and memory measurements meet target on Java, or miss it
Android	Legacy holdover	New code is written in Kotlin; Java remains in existing apps	You publish an SDK that Java callers consume

Three conditions decide when to pick Java for a workload:

1. Choose Java by default when the system will live for many years and a large team has to operate it.
2. Compare alternatives when the service is small and startup time or memory footprint is the main cost driver.
3. Avoid Java for new Android screens, since the platform tooling targets Kotlin.

Enterprise and fintech. Spring Boot is the default framework for new Java services, and most teams pair it with an LTS release such as Java 17 or Java 21. Our guide to Java backend frameworks compares the options.

Banks and payment providers often keep Java because rewriting a working core ledger adds risk that a new language may not repay. That risk is the reason fintech sits in the default row.

Big data. Apache Kafka moves event streams between services, and Apache Spark processes large volumes of data quickly and works well with machine learning tasks. Together they underpin data processing, AI, and cloud pipelines.

You can write Spark jobs in Python, but the cluster still runs on the JVM. Java skills therefore help with tuning and debugging when a job slows down or runs out of memory.

Cloud-native. Java 21 made virtual threads final through JEP 444, which lets a blocking, thread-per-request service handle high concurrency without reactive code. That removes one of the main reasons teams left Java for newer runtimes.

Go and Node.js still tend to win on small services where startup time and memory footprint dominate. We would measure the service's profile before standardizing on either.

Android. Google's Kotlin-first guidance steers new Android work to Kotlin, while existing Java code keeps its support.

Java stays relevant for maintaining existing apps, so don't start a greenfield mobile project in it. For a wider list, see what Java is used for.

Is Java still used for Android development?

Java is still used on Android, mostly in existing code, while Kotlin-first Android development governs new work. Android Developers documentation describes the platform as Kotlin-first: new Jetpack libraries and Jetpack Compose target Kotlin (Android Developers, 2024).

Our recommendation is to write new code in Kotlin, leave stable Java modules alone, and mix the two inside one module file by file. Kotlin and Java sources compile together under the Android Gradle plugin and call each other directly, so no migration project needs scheduling.

A working rule set for a mixed module:

1. Write new screens, ViewModels, and features in Kotlin.
2. Convert a Java file only when a feature or bug fix already requires editing it.
3. Annotate Java boundary types with @Nullable and @NonNull, so Kotlin sees the declared nullability and avoids unchecked platform types.

This rule has two limits. A library or SDK consumed by third-party Java apps may keep a Java public API, since Kotlin idioms such as coroutines and default arguments read awkwardly from Java callers. A team with no Kotlin experience should also budget ramp-up time before the first Compose screen ships.

Are Java developers still in demand?

Java developers are still in demand. For a hiring company, the useful signal is the split between the junior pool and the senior pool.

Junior and mid-level Java developers are the easier hires, and Spring Boot experience is the skill most backend job descriptions ask for. Senior developers are the scarce, expensive part of the market, and that is where a smaller firm competes with banks and large vendors.

A company hiring Java developers should treat the senior pool as a limited resource and spend it on decisions that are expensive to reverse: JDK distribution, framework version, and upgrade policy. Juniors and mid-level developers can then build inside those guardrails. The table below maps common situations to a hiring order.

Your situation	Hire first	Reason
New Spring Boot service on Java 21, team under 10	1-2 seniors, then mid-level	Seniors set architecture and upgrade rules before the codebase hardens
Java 8 codebase, javax-to-jakarta migration ahead	Senior or contractor with migration experience	Spring Boot 3 requires Java 17 or later, so the move touches the whole dependency tree
Stable product, 5+ developers in maintenance	Juniors with a senior reviewer	The codebase is documented by its own tests, and onboarding cost is low

Our recommendation is to hire one senior for every four to five juniors or mid-level developers. That ratio is a judgement call, not a benchmark, and it shifts upward if you run a migration or a high-throughput system on virtual threads.

If you cannot match a bank's senior offer, train internally: a junior pool that learns on a well-maintained Spring Boot codebase is usually cheaper to build than a senior one is to buy.

Is Java still relevant against Python, Kotlin, Go and C#?

Java is still relevant against Python, Kotlin, Go and C#, because each language wins a different workload and Java wins long-lived enterprise backends built on Spring Boot. If C# is the closest rival on your shortlist, our Java vs C# comparison covers it in detail.

Java and Python rarely compete for the same project: Python is the default for data and ML work, and Java is the default for transaction-heavy services that stay in production for a decade.

The comparison below is our judgement of typical use, not a measured benchmark:

Language	Typical workload	Hiring pool	Runtime profile
Java	Enterprise backends, banking and fintech, large microservice estates	Deep, with a strong mid-level pool and a thinner senior pool	JIT-compiled, high sustained throughput, slower warm-up; virtual threads (Java 21) and native image reduce the gap
Python	Data, ML, scripting, internal tools	Very deep, but skewed toward data and scripting skills	Interpreted, slower on CPU-bound code, fast to prototype
Kotlin	Android apps, JVM backends	Narrower, concentrated in mobile	Same JVM and libraries as Java, terser code
Go	Infrastructure tooling, small network services	Smaller, growing	Static binary, fast startup, low memory footprint
C#/.NET	Enterprise backends, Windows and Azure shops	Deep inside Microsoft-centric markets	Managed runtime with JIT and AOT options, close to Java's profile

Kotlin is the one language on the list that complements Java, since it runs on the same JVM and calls Java code directly.

On the server, Spring Boot supports Kotlin directly, so a team can adopt it service by service without leaving the JVM. Teams planning a Kotlin-first Android build can also look at specialist Android app development services to speed up delivery.

The hiring column varies by city and seniority, so check it against your own local market before treating it as settled. For teams under about ten engineers building a greenfield product with no JVM history, Python or Go will usually get a first version out faster. That advantage narrows once the service needs sustained throughput and years of maintenance.

Is Java outdated? Release cadence, LTS versions and modern features

Java is not outdated: OpenJDK ships a feature release every six months and an LTS release every two years, and Java 25 is the current LTS.

Features that once pushed teams toward other languages, such as verbose data classes and thread-per-request limits, now ship as records and virtual threads.

Records, for example, were finalized in Java 16 and reached LTS users with Java 17, and our list of Java 17 features covers the rest of that release.

The three LTS releases a team is likely to run in 2026, with Premier Support dates from the Oracle Java SE Support Roadmap:

LTS release	Released	Oracle Premier Support ends	Features that matter for upgrades
Java 17	September 2021	September 2026	Records, sealed classes, pattern matching for instanceof, strong encapsulation of JDK internals (JEP 403); minimum version for Spring Boot 3
Java 21	September 2023	September 2028	Virtual threads from Project Loom (JEP 444), record patterns, pattern matching for switch, generational ZGC
Java 25	September 2025	September 2030	Scoped values, compact object headers, flexible constructor bodies, module import declarations

Premier Support is an Oracle JDK term. Eclipse Temurin, the Eclipse Adoptium build of OpenJDK, follows its own update schedule, so check the Adoptium support page for the distribution you deploy.

Virtual threads are the feature that changes architecture decisions. They let a blocking, thread-per-request service handle far more concurrent connections without moving to reactive code, but they do not speed up CPU-bound work.

One upgrade detail decides between 21 and 25. On Java 21, a virtual thread blocked inside a synchronized block pins its carrier thread. JEP 491 removed that limitation in Java 24, which makes 25 the first LTS where legacy locking code behaves well under virtual threads (InfoQ: Virtual Threads after JDK 24).

We recommend moving Java 8 and 11 estates straight to 21 or 25 and using 17 only where a dependency blocks the newer versions. Oracle's Premier Support for 17 ended in September 2026, and the jump from 8 costs the same migration work whichever target you pick.

That work has two parts:

• Namespace migration: javax. becomes jakarta. for Jakarta EE 9+ and Spring Boot 3+.
• Internal API access: libraries that reach into JDK internals through reflection break under strong encapsulation.

Budget for both before estimating the upgrade. A codebase that depends on old application servers or unmaintained libraries will take longer than one on current Spring Boot.

Does Java still fit cloud-native work?

Java fits cloud-native work in 2026 if you budget for what its two cloud-native features cost. Virtual threads (Project Loom) help only I/O-bound services, and GraalVM native image buys fast startup at the price of build time and peak throughput. Quarkus and Spring Boot's AOT processing reduce that price without removing it.

The failure modes, with the early sign of each and the usual fix:

Feature	Where it breaks	Early sign	Mitigation
Virtual threads	CPU-bound work: more threads add no cores	CPU saturated, latency unchanged after migration	Keep a bounded platform-thread pool for compute-heavy tasks
Virtual threads	synchronized blocks on JDK 21 pin the carrier thread during blocking calls	Throughput plateaus; jdk.VirtualThreadPinned events in JFR	Switch to ReentrantLock, or move to a JDK that includes JEP 491
Virtual threads	Pools sized for platform threads, such as a fixed executor or a small JDBC pool	Requests queue on the pool while CPU idles	Stop pooling virtual threads; cap concurrency with semaphores; size the database pool to database capacity
Native image	Reflection, dynamic proxies and resource loading need explicit configuration	Missing-class or missing-method errors at runtime only	Quarkus extensions generate most metadata; run the tracing agent for the rest
Native image	Slower builds and lower peak throughput than the JIT	CI minutes grow; a long-running service is slower after warmup	Reserve native image for scale-to-zero and short-lived workloads

Virtual threads make blocking code cheap, but they do nothing for the bugs that come with shared state. Poor thread handling still produces deadlocks and race conditions, and cheaper threads make it easier to create contention you never load-tested.

Our view: run the JIT on JDK 21 or later for steady, long-running services, and use native image where cold-start time sets your cost, as in functions, scale-to-zero jobs and CLI tools. That split is a judgement call, not a benchmark result.

Teams with heavy reflection-based libraries should prototype the native build before committing, because the configuration work grows with the dependency tree.

If a legacy estate stands in the way of moving to JDK 21 or trying native image, application modernization services can help untangle that technical debt without disrupting production.

Why is Java 8 still used, and what does staying on it cost?

Java 8 persists because moving to Java 17 or 21 runs into three blockers that a recompile does not fix, and staying means depending on vendor patches. Oracle ended public updates of Java 8 for commercial use in January 2019 (Oracle Java SE Support Roadmap). Since then, security fixes come from a paid subscription or a free build such as Amazon Corretto.

The blockers, with the early sign of each and the usual fix:

Blocker	Early sign	Usual fix
javax-to-jakarta rewrite: Spring Boot 3 and Spring Framework 6 require Java 17 and the Jakarta EE namespace	Compile errors on javax.servlet or javax.persistence imports; starters with no Jakarta release	Upgrade to Spring Boot 2.7 first, run OpenRewrite's Jakarta migration recipes, then replace libraries that never shipped a Jakarta version
Libraries using removed or encapsulated JDK internals	NoClassDefFoundError for javax.xml.bind (JAXB left the JDK in Java 11, JEP 320); InaccessibleObjectException at startup (strong encapsulation by default since Java 17, JEP 403)	Add JAXB as an explicit dependency, upgrade the library, and use --add-opens only as a short-lived bridge
App servers certified only for Java 8	The vendor's support matrix lists no newer JDK for your server version	Move to a Jakarta EE release certified on Java 17+, or repackage the app on embedded Tomcat or Jetty

Staying on Java 8 has a price in four places:

• Spring Boot 2.7, the last line that runs on Java 8, no longer gets open-source releases. Patches for it now come only through commercial Spring support.
• Every Java 8 vendor build has its own end date. Amazon Corretto 8 end of support is December 2030 (Amazon Corretto FAQ).
• Newer library releases drop Java 8 baselines, so dependency upgrades start to fail.
• Your hiring pitch has to sell a decade-old runtime.

Support options split into free and paid. Amazon Corretto and Eclipse Temurin publish free Java 8 updates, while Oracle Java SE Subscription, Azul, and Red Hat sell contractual support with SLAs. Free builds close the patch gap but not the dependency gap.

We recommend the free vendor build as a bridge and a two-step upgrade, Java 8 to Spring Boot 2.7, then to Java 17 and Spring Boot 3, so the namespace rewrite is isolated from the runtime change. A frozen internal tool with no external exposure can reasonably stay on a patched Java 8 build until its retirement date.

Is Java dead? What is gone and what is not

Java is not dead: what OpenJDK has removed is the browser-era client stack, while the server platform, including Jakarta EE and Spring Boot, keeps shipping on a six-month cadence. Whether a given piece is gone depends on which layer you ask about.

The status of each piece, side by side:

Component	Status in 2026	What to do
Applets and browser plug-in	Applet API deprecated for removal in JDK 17 (JEP 398), with removal tracked in a later JEP	Treat as dead. Rebuild as a web front end
Java Web Start	Dropped from Oracle JDK in version 11 and never part of OpenJDK builds	Ship installers with jpackage or move to a web app
Swing and AWT	Still in the java.desktop module and maintained, with no removal planned	Keep existing apps. Rarely the right start for new work
Server platform	Jakarta EE under the Eclipse Foundation, Spring Boot, and virtual threads final in Java 21 (JEP 444)	Active, and where new Java investment goes

The removals that cost server teams time are in the namespace. Jakarta EE 9 renamed javax. packages to jakarta., and Spring Boot 3 followed with a Java 17 baseline. Libraries pinned to the old namespace are the usual reason a Java 8 estate stalls, which the previous section covers.

This split holds for backend and tooling work. A team whose product is a browser-delivered Java client has no supported path left and should plan a rewrite.

Is Java Swing still used?

Yes, Java Swing is still used, mostly in legacy desktop tools, and we recommend maintaining those applications while choosing another UI stack for new desktop work.

Swing remains part of OpenJDK in the java.desktop module and has not been deprecated for removal, so existing apps run on current LTS releases.

The decision rule we'd suggest:

• Keep Swing when the app works, the team knows it, and the roadmap is bug fixes. Spend the budget on a current LTS, HiDPI scaling and a modern look and feel such as FlatLaf.
• Pick another stack for new work. JavaFX (OpenJFX) fits a Java-only team building a desktop-only product. Compose Multiplatform suits Kotlin teams. A web client or Tauri gives you a larger hiring pool.

The exception is a large Swing codebase with heavy custom components. A rewrite there rarely pays back unless users are asking for features Swing can't deliver.

Why do enterprises keep Java?

Enterprises keep Java because backward compatibility and long vendor support for LTS releases lower migration risk. A Java build also runs across operating systems unchanged, which saves the time and money a porting effort would take on other stacks.

The cost sits on the other side: drift behind the current LTS. Compatibility protects business logic, while the dependency stack stays exposed. Code compiled years ago usually runs on Java 17 or Java 21, and breaks come from removed APIs and tightened internals. JEP 403 strongly encapsulated JDK internals in Java 17, which breaks libraries that relied on reflective access.

Drift compounds. Spring Boot 3 requires Java 17 or later and builds on the jakarta. namespace from Jakarta EE. A team still on Spring Boot 2 and javax. faces the namespace migration and a JDK jump in one move.

Choice	Migration risk	Cost of drift	Fits when
Hold an old release	Low today, rising each year	Namespace migration, library lockout, possible paid extended support	Certification freezes the runtime
Step from LTS to LTS	Low: each hop changes one baseline	Small and regular	Most teams with active development
Rewrite in another language	High: hiring, retraining, re-testing	Variable, and proven behavior is lost	A driver exists beyond the JDK version

Early signs that drift is turning into a bill:

• A framework upgrade requires a newer JDK than the one you run.
• Key libraries still target javax. while the industry moves to jakarta..
• Reflective access errors appear after a JDK upgrade.
• Your release approaches the end of free vendor support.

Staying current also pays back. Teams on a supported LTS line can gain speed over time, and optimizing Java code for the newer runtime may deliver enough to postpone any rewrite discussion. Java 21 finalized virtual threads, and Spring Boot 3.2 and later can run request handling on them with a single property, so blocking-style services can scale without a reactive rewrite.

Our decision rule: upgrade from LTS to LTS on a fixed cadence. If certification freezes the runtime, hold the version deliberately and budget the namespace migration as a planned project. Consider a rewrite only when a separate driver exists, since compatibility and support do not address it.

Should you choose Java for your next project?

Choose Java for a long-lived backend where Spring Boot, JVM skills and hiring depth matter, and pick another language for ML-heavy work, small scripts, or teams without JVM experience.

The decision comes down to workload and team, and this table maps common situations to a default:

Situation	Default pick	Reason
Long-lived transactional backend (banking, billing, ERP integration)	Java with Spring Boot	Mature framework, large hiring pool, upgrade path between LTS releases
Cloud-native services with tight startup and memory budgets	Java with Quarkus, or Spring Boot native image	Faster startup and smaller footprint for containers and scale-to-zero
High-concurrency services written in blocking style	Java 21 or later	JEP 444 keep thread-per-request code without a reactive rewrite
Team wants concise syntax on an existing JVM stack	Kotlin	Interoperates with Java libraries and Spring Boot, so adoption can be incremental
New Android app	Kotlin	Jetpack libraries and Compose target Kotlin first
Model training, data science, notebooks	Python	The ML tooling lives there; Java usually serves trained models
Small scripts, CLIs, glue code	Python or Go	JVM startup and build tooling cost more than the task is worth
Small team, no JVM skills, prototype due soon	Go, TypeScript or Python	Maven or Gradle setup and framework conventions slow the first release

We recommend Java with Spring Boot as the default for service backends expected to live five years or more, and Quarkus when container density or cold-start time drives cost. Treat Kotlin as a language choice on the same platform.

The last two rows are judgement, not benchmark results. A team with strong Java engineers can ship a prototype in Java faster than it can learn Go, so weigh the skills you have today before the language's reputation. Our Java pros and cons article covers the trade-offs behind these defaults.

Is Java still worth learning in 2026?

Yes, if you are aiming at backend, fintech or big data work, where Java is the default runtime and Spring Boot is the common framework. For Android, learn Kotlin first, and for data science or ML, start with Python. Java's syntax and the JVM carry over to Kotlin, so the time is not lost if you switch later.

The verdict

Java is still used in 2026, and it stays the default for long-running transactional backends when your team or hiring pool already knows the JVM. If you are weighing a Java 8 migration or a new backend build, our Java development services page outlines how we approach both.