Spring Boot Scala Sbt IntelliJ here in 2026 Which java version should we choose

Mike Møller Nielsen explains how to choose the correct Java version for a Spring Boot project using Scala, sbt, and IntelliJ.

Trying to decide which Java version to use for a Spring Boot project with Scala, sbt, and IntelliJ can get confusing fast, especially when compatibility, tooling, and long-term maintenance all matter at the same time. In this video, I walk through the practical decision-making process for choosing the right Java version for a modern Spring Boot and Scala setup in IntelliJ using sbt, with a focus on what actually works well in real development environments. I cover the tradeoffs between different Java versions, how they relate to Spring Boot support, and why that choice affects your build, dependency management, IDE behavior, and deployment strategy. When Scala is part of the stack, the Java version decision is not just about language features. It also affects compiler compatibility, plugin support, test execution, and the overall stability of the project inside IntelliJ and sbt. This video is especially useful if you are building backend services with a mixed Java and Scala ecosystem and want to avoid wasting time on version mismatches. I focus on the practical side of setting up a project so that Spring Boot, Scala, sbt, and IntelliJ work together cleanly without hidden friction. Topics covered include: - choosing a Java version for Spring Boot projects that use Scala - understanding how sbt and IntelliJ react to different JDK selections - avoiding compatibility issues between Scala, Spring Boot, and the Java runtime - thinking about long-term support and team maintainability - reducing setup problems before they affect development and deployment A specific technical use case I discuss is a Scala-based Spring Boot microservice that consumes order events from Kafka, transforms them into domain objects, validates business rules, and writes the results into PostgreSQL while exposing operational endpoints through Spring Boot Actuator. In that kind of service, the Java version matters because it influences container base image selection, memory behavior in production, dependency compatibility, test reliability in CI, and whether the same project imports and runs correctly across multiple developer machines in IntelliJ. I also look at the question from the perspective of real project setup rather than theory. If you are creating a service template, maintaining an internal platform starter, or trying to standardize development across a team, choosing the wrong JDK can create unnecessary friction later. A version that seems fine at first can lead to subtle issues with builds, plugin behavior, local execution, or deployment pipelines. That is why I focus on a choice that is practical, supportable, and aligned with the rest of the toolchain. If you are working with Spring Boot and Scala together, this topic is more important than it may seem. A clean setup starts with the right Java baseline, and that decision affects everything that comes after it, from project generation to packaging, testing, and production rollout. I go through the reasoning in