You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Jeremy Landis (Jira)" <ji...@apache.org> on 2020/03/28 20:35:00 UTC
[jira] [Comment Edited] (MCOMPILER-339) Skip --release flag if
compilerVersion is lower than 1.9
[ https://issues.apache.org/jira/browse/MCOMPILER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070024#comment-17070024 ]
Jeremy Landis edited comment on MCOMPILER-339 at 3/28/20, 8:34 PM:
-------------------------------------------------------------------
Hi [~rfscholte], That results in hard-coding that isn't easily controlled. I had to use spring boot styled property setup and already have numerous profiles for that. Its extremely complicated that I cannot just state <maven.compiler.release>x</maven.compiler.release> as root property outside of a profile and it work down to jdk 8 which is lowest jdk we allow. We fully have animal sniffer compiled globally as well and further are using enforcer extra to ensure binary compatibility of other jars which none of this even accounts for. I find this too hard lined as even your comments in 2018 suggested to make a property available to avoid such issue here. I presume that was just this. This is why echo of a warning (ie maven.compiler.release set to 8 but not applied due to jdk 8 usage, use jdk 9 or better for that parameter). The idea is to allow some flexibility here as the jdk is too hard on this and will fail compilation. The profile does work, but it requires a significant amount of additional configuration. All of which I'm past but I would prefer to cleanup my configuration. My use case is 400+ repos using same parent super pom that supports builds on jdk 8, 9, 10, 11, 12, 13, 14, or 15 currently. Thus it is extremely complicated for me in general and a pain in my opinion. The danger is what? That the compiler at runtime will fail with wrong class error when loaded? That happens almost immediately under most circumstances and 'release' itself again doesn't protect any third party dependencies compiled with higher jdks anyways (I wish it did). So the issue it suggests to fix is still present even with 'release' or animal sniffer. 'release' improves a bit as it will prevent java agents during build that are higher jdk but that is effectively it.
was (Author: hazendaz):
Hi [~rfscholte], That results in hard-coding that isn't easily controlled. I had to use spring boot styled property setup and already have numerous profiles for that. Its extremely complicated that I cannot just state <maven.compiler.release>x</maven.compiler.release> as root property outside of a profile and it work down to jdk 8 which is lowest jdk we allow. We fully have animal sniffer compiled globally as well and further are using enforcer extra to ensure binary compatibility of other jars which none of this even accounts for. I find this too hard lined as even your comments in 2018 suggested to make a property available to avoid such issue here. I presume that was just this. This is why echo of a warning (ie maven.compiler.release set to 8 but not applied due to jdk 8 usage, use jdk 9 or better for that parameter). The idea is to allow some flexibility here as the jdk is too hard on this and will fail compilation. The profile does work, but it requires a significant amount of additional configuration. All of wish I'm past but I would prefer to cleanup my configuration. My use case is 400+ repos using same parent super pom that supports builds on jdk 8, 9, 10, 11, 12, 13, 14, or 15 currently. Thus it is extremely complicated for me in general and a pain in my opinion. The danger is what? That the compiler at runtime will fail with wrong class error when loaded? That happens almost immediately under most circumstances and 'release' itself again doesn't protect any third party dependencies compiled with higher jdks anyways (I wish it did). So the issue it suggests to fix is still present even with 'release' or animal sniffer. 'release' improves a bit as it will prevent java agents during build that are higher jdk but that is effectively it.
> Skip --release flag if compilerVersion is lower than 1.9
> --------------------------------------------------------
>
> Key: MCOMPILER-339
> URL: https://issues.apache.org/jira/browse/MCOMPILER-339
> Project: Maven Compiler Plugin
> Issue Type: Improvement
> Affects Versions: 3.7.0
> Reporter: David J. M. Karlsen
> Priority: Major
>
> usecase: I have a build which is jdk10 by default, declared via the parent-pom.
> However, one submodule must be compiled and run with java8. I had hoped to get this working, by setting:
> {noformat}
> <properties>
> <maven.compiler.release>8</maven.compiler.release>
> <maven.compiler.source>1.8</maven.compiler.source>
> <maven.compiler.target>1.8</maven.compiler.target>
> <maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
> </properties>
> {noformat}
>
> but it will fail with
> {noformat}
> Caused by: java.lang.IllegalArgumentException: invalid flag: --release*11:53:45* at com.sun.tools.javac.api.JavacTool.processOptions (JavacTool.java:206)*11:53:45* at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:156)*11:53:45* at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:107)*11:53:45* at com.sun.tools.javac.api.JavacTool.getTask (JavacTool.java:64)*11:53:45* at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess (JavaxToolsCompiler.java:125)*11:53:45* at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile (JavacCompiler.java:174)*11:53:45* at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:1075)*11:53:45* at org.apache.maven.plugin.compiler.TestCompilerMojo.execute (TestCompilerMojo.java:176)*11:53:45* at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:134)*11:53:45* at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)*11:53:45* at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)*11:53:45* at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)*11:53:45* at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)*11:53:45* at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:200)*11:53:45* at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:196)*11:53:45* at java.util.concurrent.FutureTask.run (FutureTask.java:266)*11:53:45* at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511)*11:53:45* at java.util.concurrent.FutureTask.run (FutureTask.java:266)*11:53:45* at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149)*11:53:45* at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:624)*11:53:45* at java.lang.Thread.run (Thread.java:748)
> {noformat}
> If the release flag could only be enabled for compiler versions supporting it it would be easier to juggle the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)