Languages & Runtimes
Want to propose a change, disagree with a placement, or add an interesting new technology? Please reach out to @Damian Szafranek. This Tech Radar is a living document - we keep it useful by updating it together as our projects, tools, and experiences evolve.
Scope
This section covers the core programming languages used for development and the runtime environments (e.g., JVM) they execute on. It specifies which languages and versions are standard, which are being explored, and which are being phased out for our back-end and mobile applications.
Overview
ADOPT
Proven technologies we have high confidence in; our default choices.
Technologies Breakdown
Java 21 (LTS) ADOPT
As our designated Long-Term Support (LTS) version, Java 21 is the standard for all new back-end projects. It provides stability, long-term security updates, and access to modern language features that enhance developer productivity and code quality.
Python ADOPT
One of our two primary backend languages, alongside Java. Reach for it for web services, data work, and anything where the library ecosystem does most of the lifting.
Most of what this radar gained in 2026 is Python, which is the case for it in itself: Django and FastAPI on the web side, Celery for background work, SQLModel and Alembic for persistence, and the toolchain of ruff, uv and ty. Start from those entries rather than from scratch, and see Django against FastAPI for the framework choice.
The version to target is a project-level decision and is not fixed here. Stay on a release that still receives security fixes, and treat a version that does not as the same kind of problem the Java entries describe.
TypeScript ADOPT
The default for all frontend work, and for any JavaScript we write. Plain JavaScript is not a choice we make for new code.
Every frontend entry on this radar already assumes it: React and Next.js, the typed client generated from an OpenAPI specification, Biome for linting and formatting, Vitest for tests. Listing it makes explicit what those entries take for granted.
Its value compounds with the contract-first approach recorded under openapi-typescript, where the server's types reach the client without anyone hand-writing them. That is the difference between types as documentation and types that fail a build.
Kotlin (for Mobile) TRIAL
We are actively trialing Kotlin in the migration of a major mobile application from Java. Its modern syntax and safety features are proving valuable, and this initiative is successfully building our internal Kotlin expertise.
Java 25 (LTS) TRIAL
Worth putting on new backend services that can absorb a newer runtime, and the natural pairing for any Spring Boot 4.x evaluation. Java 25 has been the current Long-Term Support release since September 2025, and Oracle Premier Support runs to September 2030, a longer runway than Java 21.
Java 21 remains our standard and there is no pressure to leave it. The case for 25 is the support runway and its alignment with the current Spring generation: Spring Framework 7 keeps a Java 17 baseline but recommends 25 for production, and has raised its GraalVM native-image baseline to 25. Migration from 21 is low risk, and the headline runtime gain is compact object headers, which needs no code changes. Note that virtual threads were finalised in Java 21, so they are not a reason to move. This becomes Adopt once a project has shipped on it.
Kotlin (for Back-end) ASSESS
Leveraging our growing in-house skills from mobile development, we are assessing Kotlin for new back-end services. Its seamless Java interoperability, concise syntax, and excellent support within the Spring ecosystem make it a strong candidate for future microservice development.
Java 17 (LTS) HOLD
Not for new projects. Oracle Premier Support for Java 17 ends on 30 September 2026, with extended support to 2029, so existing services on it are still supported but no longer current. Plan an upgrade to Java 21, our standard, at the next reasonable opportunity.
Java 17 is in a different position from Java 8 and 11: it is a recent LTS, still a common library baseline, and the upgrade to 21 is usually small because there are no module-system or Jakarta namespace hurdles between them. It sits at Hold because it is no longer the current LTS and its premier support window is closing, not because it is risky to run today. Treat the migration as routine maintenance to schedule rather than an incident to respond to.
Java 8 & 11 (LTS) HOLD
Restricted to legacy projects in maintenance, and a security concern rather than a matter of preference. Both are well past Oracle Premier Support, so fixes now depend on paid extended support or a third-party OpenJDK build. No new work on either, and every remaining application should have an active migration plan to Java 21.
These versions predate the language and platform improvements our current work assumes, and upgrading from them is a real project rather than routine maintenance: Java 8 to 11 crosses the module system, and anything on a Spring Boot 2.x line will need that upgrade too. That coupling is why the migration keeps being deferred, and why it needs to be planned deliberately with the Spring Boot upgrade rather than treated as a runtime bump.