0

I just found out, that IntelliJ behaves very peculiarly when configuring the maven-compiler-plugin with <release> only:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.8.0</version>
  <configuration>
    <release>14</release>
  </configuration>
</plugin>

As a result after reloading the Maven project, in the 'Java Compiler' preferences, it displays target bytecode level 8 instead of the expected 14. I guess it was inferred because the modules didn't use any Java 14 features, yet.

see preferences screenshot: https://i.stack.imgur.com/gqpKV.jpg

In comparison, when adding <source> and <target> the IDE configures its own configuration, correctly.

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

see preferences screenshot: https://i.stack.imgur.com/gqpKV.jpg

As far as I understand it, the javac --release option is slightly more reliable than just defining -source and -target because it additionally sets the -bootclasspath option to the correct level (double-checked with this SO post). So it seems to me that relying on this option exclusively is a better practice.

Is there another configuration step that I would have to execute in order to make IntelliJ set up the preferences, correctly, without declaring the older parameters?

dgins
  • 11
  • 1
  • If you use in in child pom then it couldn't override settings from parent pom: https://youtrack.jetbrains.com/issue/IDEA-199818 – y.bedrov Sep 15 '20 at 11:49
  • I indeed got a parent-pom that configures the plugin in its , but I override that config in my child-pom with the newer Java version. So I assumed that should trigger IntelliJ to read the property correctly but it doesn't. /headscratch but thanks for linking the ticket, maybe I can get more out of that and find a solution : ) – dgins Sep 15 '20 at 12:12

1 Answers1

1

I investigated that issue a little closer and found out that somewhere in one of the parent poms the maven-compiler-plugin was added to the <pluginManagement> with a maven-property that got never set for the configuration.

This seemed to have caused IntelliJ to infer by language level even though I overwrote the plugin configuration in the child-pom.

I guess that's acceptable behaviour because if the parent pom is faulty, IntelliJ shouldn't try too hard to figure out stuff on its own to just cause more confusion.

dgins
  • 11
  • 1