[
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)
