Fix “Source Release 8 Requires Target Release 1.8” in IntelliJ Java

This error means the Java compiler was asked to accept Java 8 source code while generating bytecode for a different, older target. You will learn how source, target, language level, JDK, and build-tool settings relate, and how to make them consistent in IntelliJ IDEA, Maven, and Gradle.

Java compilation has two related version settings:

• Source release controls which Java language syntax is accepted, such as lambdas and method references in Java 8.
• Target release controls the version of JVM bytecode produced by the compiler.

For example, Java 8 source code can use this lambda expression:

List<String> names = List.of("Ada", "Linus");
names.forEach(name -> System.out.println(name));

That syntax requires source level 8 or newer. When compiling as Java 8, javac expects Java 8 bytecode as well: target 1.8 (often shown as 8 in modern tools).

The error occurs when settings effectively look like this:

-source 8 -target 1.7

The compiler rejects that combination because Java 8 language features cannot safely be compiled for a Java 7 bytecode target.

In IntelliJ IDEA, several places can affect these values:

• Project SDK
• Project language level
• Module SDK and language level
• Settings → Build, Execution, Deployment → Compiler → Java Compiler → Target bytecode version
• Maven or Gradle build configuration

A build tool configuration can override what is selected in the IntelliJ project settings.

Think of Java source code as a document written in a particular version of a language, and bytecode as the file format used to distribute that document.

• Source level is the language edition you write in.
• Target level is the version of the reader that must be able to open the final file.

If you write using Java 8 grammar but try to save the result in the older Java 7 bytecode format, the compiler cannot guarantee that the older runtime understands it. Set both to Java 8 when the project is intended to use Java 8.

The command-line form of the mismatched configuration is:

javac -source 8 -target 1.7 App.java

It fails because Java 8 source requires a Java 8 target.

Use matching values instead:

javac -source 8 -target 1.8 App.java

Example Java 8 program:

import java.util.Arrays;

public class App {
    public static void main(String[] args) {
        Arrays.asList("red", "blue", "green")
              .forEach(color -> System.out.println(color));
    }
}

The lambda expression color -> ... is a Java 8 feature. Compile it with Java 8 source and target settings.

When compiling with JDK 9 or newer, prefer --release when possible:

javac --release 8 App.java

--release 8 selects a compatible language level, bytecode target, and standard-library API set for Java 8. It helps prevent accidentally calling APIs that did not exist in Java 8.

Consider this command:

javac -source 8 -target 1.7 Greeting.java

And this file:

public class Greeting {
    public static void main(String[] args) {
        Runnable task = () -> System.out.println("Hello");
        task.run();
    }
}

Step by step:

1. -source 8 tells javac to parse Java 8 syntax, including () -> ... lambdas.
2. -target 1.7 asks javac to create Java 7-compatible .class files.
3. Before compilation finishes, javac detects that source level 8 requires target 1.8.
4. Compilation stops with the reported error.
5. Change the target to 1.8, or use --release 8:

javac -source 8 -target 1.8 Greeting.java

1. The compiler creates Java 8 bytecode, and the program can run on a Java 8-or-newer runtime.

Matching source and target versions matters whenever an application must run in a specific Java environment:

• Legacy server deployment: A service runs on Java 8 in production, so builds must produce Java 8-compatible classes.
• Desktop applications: A team supports users with a particular installed Java runtime.
• Libraries: A library may promise Java 8 compatibility even though developers build it on a newer JDK.
• CI pipelines: A CI server may use a different JDK from local IntelliJ installations, so the build must declare its intended release.
• Multi-module systems: One module may need Java 8 compatibility while another module can use a newer Java release.

In real projects, the build configuration should be the source of truth. IntelliJ should import and follow Maven or Gradle settings rather than relying only on IDE-specific compiler options.

Maven

For modern Maven Compiler Plugin versions, configure a release:

<properties>
    <maven.compiler.release>8</maven.compiler.release>
</properties>

For older configurations, keep source and target aligned:

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

Gradle

Use Java toolchains to declare the intended Java version:

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

Or, when compiling on a newer JDK for Java 8 compatibility:

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

IntelliJ IDEA

For a non-Maven/non-Gradle project:

1. Open File → Project Structure.
2. Set the Project SDK to an installed JDK that can compile the required version.
3. Set the Project language level to 8 - Lambdas, type annotations, etc. when the project uses Java 8.
4. Open Settings → Build, Execution, Deployment → Compiler → Java Compiler.
5. Set the project or affected module Target bytecode version to 8 or 1.8.
6. Rebuild the project.

If the project uses Maven or Gradle, update the build file first and then reload the project in IntelliJ.

Changing only the language level

The language level affects editor inspections and may affect compilation, but it is not always the only source of compiler settings. The target bytecode setting or build tool can still request Java 7.

Language level: 8
Target bytecode: 1.7   ← still incorrect

Set the target to 1.8/8 too.

Assuming the Project SDK alone fixes it

Selecting a JDK 8 SDK does not necessarily override an explicit module, compiler, Maven, or Gradle target setting. Check the effective build configuration.

Mixing 8 and 1.8 incorrectly

Java tools historically use both notations:

• 1.8 is the traditional javac -target value for Java 8.
• 8 is common in IDE menus and --release 8.

Follow the format required by the tool you are configuring.

Setting source to 8 but target to 7

This is the direct cause of the error:

<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>

Correct it:

<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>

Editing IntelliJ settings while Maven or Gradle controls the build

A Maven or Gradle reload can restore values from the build file. Put the version setting in pom.xml or build.gradle and reload the project.

Using -source and -target without checking APIs

With a newer JDK, -source 8 -target 1.8 can still allow use of newer JDK APIs during compilation. Prefer --release 8 when available to catch such incompatibilities.

-source and -target versus --release

JDK versus JRE

IntelliJ needs a JDK, not only a JRE, to compile a Java project.

• Java 8 source must use Java 8 target bytecode: -source 8 -target 1.8.
• In IntelliJ, check Target bytecode version under Settings → Build, Execution, Deployment → Compiler → Java Compiler.
• Set Project SDK, module SDK, language level, and target bytecode consistently.
• Maven:

<maven.compiler.release>8</maven.compiler.release>

• Older Maven setup:

<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>

• Gradle on a newer JDK:

options.release = 8

• Prefer javac --release 8 on JDK 9+.
• If IntelliJ settings seem ignored, Maven or Gradle is probably supplying the effective compiler configuration.
• After changing build configuration, reload the Maven/Gradle project and rebuild.

What does “source release 8 requires target release 1.8” mean?

It means the compiler is configured to accept Java 8 syntax but is configured to generate bytecode for a version older than Java 8. Set the target to Java 8 as well.

Is Java 8 the same as Java 1.8?

Yes in this context. Java 8 is the product name, while 1.8 is the older version notation used by some Java compiler options.

Where do I set target bytecode version in IntelliJ IDEA?

Open Settings → Build, Execution, Deployment → Compiler → Java Compiler and set the project or module target bytecode version to 8 or 1.8.

Why does IntelliJ still show the error after I change the Project SDK?

The compiler target may be set separately, or Maven/Gradle may override IDE settings. Check the module compiler target and the project's build file.

Should I use source and target, or release?

Use release when building with JDK 9 or newer. It also checks that your code only uses standard-library APIs available in the selected Java release.

Can Java 8 bytecode run on Java 7?

No. Java bytecode is generally forward-compatible: Java 8 bytecode runs on Java 8 or newer, not on Java 7.

Do I need JDK 8 to build code that targets Java 8?

Not always. A newer JDK can compile for Java 8 with --release 8. However, JDK 8 is still useful when a project specifically requires its tooling or environment.

• Java JDK and JRE — Understand the difference between a compiler toolkit and a runtime.
• Java bytecode — Learn why compiled .class files have JVM compatibility versions.
• Java language levels — See how language features such as lambdas are tied to Java releases.
• Maven Compiler Plugin — Configure source, target, and release versions in Maven projects.
• Gradle Java toolchains — Select reproducible JDK versions for Gradle builds.
• IntelliJ IDEA project SDKs — Configure the JDK used by an IntelliJ project and its modules.
• Java compatibility — Learn how to support older Java runtimes safely.