Which JDK is IntelliJ IDEA using for your project? – Support | JetBrains

Background

IntelliJ IDEA can work with more than one JDK in the same project. One JDK may run your application, another may run Maven or Gradle, and the project may still have its own SDK and language level settings.

The IDE also has its own runtime, but that is not the same thing as the JDK used to develop or run your Java application.

So when the Run console prints an unexpected Java version, do not check only one place. Start with the Run Configuration, then check the project/module SDK and build tool settings.

To see the JDK used by the running application, print:

System.out.println("java.version = " + System.getProperty("java.version"));
System.out.println("java.home = " + System.getProperty("java.home"));

Plain Java project

1. Run/Debug Configuration

Path: Run | Edit Configurations | <your configuration> | JRE

This setting controls the JDK used to start that application. If it is set to a specific JDK, it wins for this run configuration. If it is not set, IDEA chooses a JDK from the selected module dependencies.

Also check Use classpath of module, because it decides which module classpath and module SDK are used.

2. Project SDK

Path: File | Project Structure | Project | SDK

This is the default SDK for the project. Modules can inherit it, so it is often the first project-level setting to check.

3. Module SDK

A module can use a different SDK from the Project SDK. In multi-module projects, this is usually more important than the Project SDK, because your run configuration is normally tied to one module.

4. Language level

Path:

File | Project Structure | Project | Language level
File | Project Structure | Modules | <module> | Sources | Language level

Language level decides which Java syntax IDEA should allow for code completion, inspections, highlighting, quick fixes, and refactoring.

It also matters for IDEA compilation. If you do not set a target bytecode version manually, IDEA uses the project language level as the target bytecode version.

Example: if the Project SDK is JDK 26 but the application must run on a Java 17 server, do not write Java 26-only syntax. Set the language level and the target/release version to 17, unless you have a special reason not to.

5. Target bytecode version

Path: Settings | Build, Execution, Deployment | Compiler | Java Compiler

Project bytecode version and Per-module bytecode version control the Java class file version IDEA should generate. Roughly, this is the minimum Java version needed to run the compiled .class files.

A safe rule for IDEA-built projects:

JDK used for compilation >= target/release version >= language level

In most normal projects, keep the language level and target/release the same.

Maven project

For Maven projects, try to keep the Java version in pom.xml. If you only change IDEA settings, Maven sync may change them back.

1. IDEA builder, not delegated to Maven

If Delegate IDE build/run actions to Maven is not enabled, IDEA uses its own builder for normal Run/Build actions. In that case, check the Run Configuration, Module SDK, Language level, and Java Compiler settings described above.

2. Delegate IDE build/run actions to Maven

When this option is enabled, IDEA builds, runs, and debugs through Maven.

The JDK that starts Maven is here:

This is the Maven JVM. It is not always the same thing as the application JVM. The real compile/run behavior can still depend on pom.xml, Maven plugins, and Maven Toolchains.

3. Maven Run Configuration

Path: Run | Edit Configurations | <Maven configuration> | Java | JRE

This JRE is used to run that Maven configuration. Use it when a Maven goal runs with the wrong Java version.

4. JDK for importer

This is used when IDEA imports, reloads, or syncs a Maven project. It is not the JDK that runs your application.

5. Maven compiler settings

Recommended simple setup:

<properties>
    <maven.compiler.release>17</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

Or configure the compiler plugin directly:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.15.0</version>
            <configuration>
                <release>17</release>
            </configuration>
        </plugin>
    </plugins>
</build>

release is usually better than only source and target, because it also checks that you do not accidentally use APIs from a newer Java version.

If you really need old-style source and target, keep them consistent:

<properties>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
</properties>

6. Maven Toolchains

Use Maven Toolchains when Maven itself should run with one JDK, but the project should compile with another JDK.

Project side: configure maven-toolchains-plugin in pom.xml.

Machine side: define JDK paths in:

~/.m2/toolchains.xml

This is useful for teams and CI, because the project asks for a JDK version and each machine decides where that JDK is installed.

7. Maven Wrapper

If the Settings | Build, Execution, Deployment | Build Tools | Maven is configured to Use Maven Wrapper, there should be mvnw or mvnw.cmd in your project root. You can configure the maven version in <project root>/.mvn/wrapper/maven-wrapper.properties .

Starting the Maven Wrapper via IDEA run configuration will still use the JDK set in Run Configuration to compile the code.

If you directly run the plugin or lifecycle from the Maven tool window, and if the JDK is not specified, it will use the same JDK used by mvnw.

You can use ./mvnw -v to check the JDK used by mvnw .

Gradle project

For Gradle projects, prefer putting Java version settings in build.gradle or build.gradle.kts. IDEA will read them after Gradle sync.

1. Build and run using

Gradle is the default option. You can switch it to IntelliJ IDEA for simple Java/Kotlin projects, but Gradle is safer when the build script does extra work.

Run tests using has the same idea: choose whether tests run through Gradle or through IDEA.

2. Gradle JVM

This JDK runs Gradle itself. It does not always decide which JDK compiles your code.

When opening an existing Gradle project, IDEA checks settings such as org.gradle.java.home, JAVA_HOME, and then a compatible installed JDK. If the value is not what you expect, check this Gradle JVM field first.

3. Gradle Java Toolchain

Recommended Gradle setup:

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

After changing it, sync Gradle.

This tells Gradle which Java toolchain to use for project tasks such as compilation, tests, and Java execution tasks.

4. Gradle release / target bytecode

If you need the output to run on a specific Java version, set options.release:

tasks.withType(JavaCompile).configureEach {
    options.release = 17
}

You can combine toolchain and release. For example, compile using JDK 21 but produce Java 17-compatible bytecode.

Quick checklist

Wrong version in the Run console

Check:

Run | Edit Configurations | <configuration> | JRE
Use classpath of module
Project Structure | Modules | <module> | Dependencies | Module SDK

Maven uses the wrong JDK

Check:

Maven Runner JRE
Maven Run Configuration JRE
pom.xml compiler settings
Maven Toolchains
JDK for importer, only if the problem happens during sync/reload

Gradle uses the wrong JDK

Check:

Gradle JVM
org.gradle.java.home in gradle.properties
JAVA_HOME
Java Toolchain in build.gradle
options.release, if the problem is target bytecode compatibility

Code compiles but fails on the server

Check the target/release version, not only the JDK installed in IDEA. The server only cares whether the generated bytecode and used Java APIs are compatible with its Java version.