Java Compiler - target bytecode version - Keeps reverting to 1.5

Answered

I have multiple modules, and some modules keep having their Target byte code being changed/reset to 1.5

I have set the Target byte code version to 1.8 (many many times), yet idea keeps changing the setting.

Additionally, when I goto Project Settings > Modules the language level is also being changed by Idea from 8 to 5.

Can someone please help.

Many thanks.

Dave.

 

 

 

20 comments
Comment actions Permalink

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.

0
Comment actions Permalink

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>

 

2
Comment actions Permalink

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.

0
Comment actions Permalink

I am getting the same issue with 2017.2 version. 

target bytecode version - Keeps reverting

0
Comment actions Permalink

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>

 

 

0
Comment actions Permalink

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?

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

 

 

 

1
Comment actions Permalink

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.

0
Comment actions Permalink

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.

 

0
Comment actions Permalink

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.

 

We don't think that it's a good idea to make CI and local build results different intentionally.

 

0
Comment actions Permalink

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?

0
Comment actions Permalink

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

0
Comment actions Permalink

Looks good. Thanks Serge.

0
Comment actions Permalink

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. 

0
Comment actions Permalink

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

0
Comment actions Permalink

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.

1
Comment actions Permalink

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

0

Please sign in to leave a comment.