Maven uses 1.5 by default. If your project is Maven based you have to override it via pom.xml configuration, see http://stackoverflow.com/a/12900859/104891 for details.

the pom already has the override:

<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
            <source>1.8</source>
            <target>1.8</target>
        </configuration>
    </plugin>
</plugins>

You may have this problem: https://youtrack.jetbrains.com/issue/IDEA-115977.

It's fixed in 2017.2: https://www.jetbrains.com/idea/nextversion/.

If the issue persists, please file a new bug at https://youtrack.jetbrains.com/issues/IDEA and attach a sample project with the steps to reproduce it.

I am getting the same issue with 2017.2 version. 

target bytecode version - Keeps reverting

to "fix" this you need to add the following properties to your maven pom:

<properties>
      <!-- necessary for intellij to function -->
      <maven.compiler.source>1.8</maven.compiler.source>
      <maven.compiler.target>1.8</maven.compiler.target>
</properties>

This affects me as well. You'd think if I change it in the settings, it would automatically add it to the POM if it needs to add project properties?

No, you must change pom.xml first, see http://stackoverflow.com/a/12900859/104891.

I know. I've already done that, and it works but what good IDE would make me manually make a change to a file I don't even know it's format? Especially if I've already changed the IDE's versions and they get REVERTED back. It's frustrating for the user, and this should NOT be the default behaviour.

IntelliJ IDEA Maven synchronization is one way only, it's mentioned in the documentation. Any changes you make in the UI that are loaded from pom.xml will be discarded on the next refresh/reimport. Normally one works on the existing project based on Maven and IDE tries to work the same as the command line Maven. Since IDE doesn't modify pom.xml files based on your UI changes, you have to modify pom.xml file directly. Maven projects can be very complex, use properties and included files to define compiler properties, there is no easy way for the IDE to recognize all the possible configurations to perform the changes in the XML automatically.

As the originator of the issue I completely disagree with the Serge's comments.

The basic function of selecting your target byte code should be remembered by the IDE.  Visual Studio does this, Eclipse does this, the plugins for VS Code do this.

I love IntelliJ, but the Jetbrains Dev team really need to up their game when it comes to the Customers experience.  Nearly every time I upgrade IntelliJ something get's "lost", default settings change, or there is a bug introduced.  Which is a shame as the product is very good, and I use the IntelliJ key settings in both VS and VS Code.

Please please please, talk about this within your Dev Team, as the attitude of the Customer is wrong is simply not acceptable when there is so competition in the IDE market place.

David, do you suggest IDE should override build system language level defaults so that you get different results in the IDE and in CI/command line?

The only correct solution would be for the IDE to change pom.xml file when you change the language level in the UI, but as I've explained, it's tricky to support and may not work correctly for complex projects defining the language level via properties, included files or parent modules.

Since you normally change the language level only once and forget about it, it's not a big deal to research how to do it properly for your build system of choice. IntelliJ IDEA will respect this setting in the build system, so you need to do it only once and in one place.

I agree that it's confusing that you can actually change these settings in the UI for the projects that are managed by the external build systems. We do plan to make it more obvious that such changes will be discarded on reimport or even make them read-only with the directions where and how the user should change them.

Using Maven i can specify the compiler version in three ways.  Two of these hard code the compiler in the POM and one is via the command line.

IntelliJ is forcing the Developer to hard code the compiler version in the POM.  

Not every Dev Team will sit comfortably with this, with some Dev Teams having their builds specify the Java Version at build time.

The IDE should never enforce the use of the compiler version, it is the Dev Team who need to specify their standards for how this is done.

However when I build using the IDE I should be able to make the IDE choose the compiler of my choice, and it should remember this.  When I check my code in and it becomes part of the CI process, then the CI environment should choose the compiler that is appropriate for it's needs.

David, we have a workaround for your specific case. You can stop IntelliJ IDEA from importing maven-compiler configuration, add the following into Help | Edit Custom VM Options, then restart IntelliJ IDEA:

-Didea.maven.disable.MavenCompilerConfigurer=true
-Didea.maven.configure.language.level=false

Hope it helps.

Not too sure on the specifics, but I do have some ideas to make the experience better.. First, my experience using the IDE, I would expect it to use my project JDK platform. I use maven solely as a dependency management solution to add libraries. This should not change the compiler target for my existing project. Second, if you really must change the POM, then why don't you create a fully managed mode? For those who created a maven project through the IDE, then put a comment in the POM where we could add. Third, you could always make sure the compiler settings are either in an 'include' that gets put into the POM like netbeans does with ant (or just make sure the settings for compiler level is always at the bottom), or make an option for us to select that we want this behavior?

I've created a new feature request, feel free to follow it for updates: https://youtrack.jetbrains.com/v2/issue/IDEA-185979.

Looks good. Thanks Serge.

Hi Serge,

I am facing same trouble of target byte code changing back to 1.5 even with

    <java.source.version>1.7</java.source.version>
    <java.target.version>1.7</java.target.version>

 these specified in pom.xml. I never faced such trouble with 2017 version. In 2017 once settings and project structure is set, everything was fine, but with 2018, its reverting back to 1.5 everytime I reimport all projects after setting it to 1.7 or 7 in target byte code version. I am using Ubuntu 14.04. Please look into this and help.

Also .iml file being generated for project is quite different from previous .iml file. 

Please report a bug at https://youtrack.jetbrains.com/issues/IDEA and attach a sample project to reproduce.

In my opinion, if the IDE is importing the setting from the POM then the IDE should not allow it to be changed except through the POM.  It should show as locked, and reference the POM.  This is much more clear than a mysteriously reverting setting, and keeps CI in line with the IDE.

Thanks for the feedback, Aaron, I've submitted another issue: https://youtrack.jetbrains.com/issue/IDEA-201247.

Hi, sorry for reanimating this thread.

I do not necessarily agree that it should be done this way; i think the developer should be able to chose. The actual Maven version should be used by default. This may be updated after each (re-)import. Change the POM if you do not like this.

But when the user choses to override this, e.g. by applying the project SDK or selecting a SDK per module, IJ should not reset this after each restart.

The project structure dialog shows the project SDK (or eventually different module SDKs) but these settings appear to be ignored when it comes to the byte code level.

And IJ shows a warning when you select something deviating from the POM default (not sure whether it is only the first time you change the SDK). 

This used not to happen very often, requiring a one-off configuration for a project, but since the last update to IntelliJ IDEA 2022.2 (Ultimate Edition), Build #IU-222.3345.118, built on July 26, 2022 (on Windows 10) it happens every single time.

(The number of modules for which this is happening in my current workspace makes this especially annoying for me though...)

Chances are that this behavior is the consequence of a fix and the previous (forgiving) behavior was in the wrong here... :P

Edit: I may have confused the language features with the byte code level or rather used both concepts synonymously. And I think - for the most parts - they are. I would not use a JDK, version X if I were not required to run the final artifact on a JRE of the same major version.

Markus Gallmetzer If you believe the current behavior is not correct, please file a bug at https://youtrack.jetbrains.com/newIssue?project=IDEA with the sample project to reproduce, provide the steps to trigger the issue, describe what you'd expect to see and describe the actual behavior you get in the IDE instead.