You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by bu...@apache.org on 2021/08/31 18:59:11 UTC
[Bug 65539] New: javac task parses command line arguments
incorrectly
https://bz.apache.org/bugzilla/show_bug.cgi?id=65539
Bug ID: 65539
Summary: javac task parses command line arguments incorrectly
Product: Ant
Version: 1.10.11
Hardware: PC
OS: All
Status: NEW
Severity: regression
Priority: P2
Component: Core tasks
Assignee: notifications@ant.apache.org
Reporter: seancleary@ie.ibm.com
Target Milestone: ---
We are moving from Apache Ant 1.10.6 to Apache 1.10.11 and we have noticed a
change in behaviour with the javac task on Linux and Windows builds which,
specifically on Windows causes a 'CreateProcess error=206, The filename or
extension is too long' error to occur. This appears to have been introduced in
Apache Ant 1.10.7 but we can still see it in 1.10.11.
Has there been changes made around the javac task between Ant 1.10.6 and 1.10.7
that might account for the changes below
Our javac task looks like this:
<javac
memoryMaximumSize="2048m"
memoryInitialSize="2048m"
fork="yes"
srcdir="C:\projectLocation\build\src"
destdir="C:\projectLocation\build\classes"
debug="on"
includeantruntime="false"
deprecation="true"
debuglevel="lines,vars,source"
classpathref="compile.cp">
<compilerarg value="-Xbootclasspath/p:${toString:xml.cp}" />
<compilerarg value="-Xmaxwarns"/>
<compilerarg value="${cmp.maxwarnings}"/>
<compilerarg line="${cmp.compilerarg}"/>
</javac>
When we run the task with Ant 1.10.6 the compilation arguments on a verbose
output looks like this:
[javac] Compilation arguments:
[javac] '-J-Xms2048m'
[javac] '-J-Xmx2048m'
[javac] '-deprecation'
[javac] '-d'
[javac] 'C:\projectLocation\build\classes\'
[javac] '-classpath'
[javac] '<<compile.cp>>' //This expands on the output to include the full
list of Jars in the compile.cp classpathref
[javac] '-sourcepath'
[javac] 'C:\projectLocation\build\src'
[javac] '-g:lines,vars,source'
[javac] '-Xbootclasspath/p:${toString:xml.cp}' //This expands on the output
to include the full list of Jars in the xml.cp classpathref
[javac] '-Xmaxwarns'
[javac] '${cmp.maxwarnings}'
When we run on the same environment and change the Ant version between 1.10.7
and 1.10.11 the compilation arguments change to:
[javac] Compilation arguments:
[javac] '-J-ms2048m' \\Change 1
[javac] '-J-mx2048m' \\Change 2
[javac] '-deprecation'
[javac] '-d'
[javac] 'C:\projectLocation\build\classes\'
[javac] '-classpath'
[javac] '<<compile.cp>> + C:\projectLocation\build\src' \\Change #3
[javac] '-g' \\ Change #4
[javac] '-Xbootclasspath/p:${toString:xml.cp}'
[javac] '-Xmaxwarns'
[javac] '${cmp.maxwarnings}'
Changes seen in verbose output:
1. memoryMaximumSize is being passed to the command line as -J-ms2048m
instead of -J-Xms2048m
2. memoryInitialSize is being passed to the command line as -J-ms2048m
instead of -J-Xms2048m
3. debuglevel is set to blank instead of lines,vars,source
4. The classpath is appended with the source directory which is new behaviour
from Ant 1.10.7+
5. sourcepath is not being set in the compilation arguments from Ant 1.10.7+
Actual results:
On Windows, we are getting the 'Create Process error=206' returned and the
javac task fails with no Java files compiled in to the destination directory
============
[transform] Clearing cached class loaders....
[transform] Cached class loaders cleared.
An error has occurred executing the build.
BUILD FAILED
C:\IBM\Curam\Development\CuramCDEJ\bin\build.xml:1152: Error running
C:\IBM\WebSphere\AppServer\java\8.0\bin\javac.exe compiler
at
org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.executeExternalCompile(DefaultCompilerAdapter.java:594)
at
org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute(JavacExternal.java:74)
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1388)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:1117)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:299)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1401)
at org.apache.tools.ant.Project.executeTarget(Project.java:1374)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1264)
at org.apache.tools.ant.Main.runBuild(Main.java:818)
at org.apache.tools.ant.Main.startAnt(Main.java:223)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:284)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:101)
Caused by: java.io.IOException: Cannot run program
"C:\IBM\WebSphere\AppServer\java\8.0\bin\javac.exe" (in directory
"C:\IBM\Curam\Development\webclient"): CreateProcess error=206, The filename or
extension is too long
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1059)
at java.lang.Runtime.exec(Runtime.java:631)
at
org.apache.tools.ant.taskdefs.launcher.Java13CommandLauncher.exec(Java13CommandLauncher.java:58)
at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:424)
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:438)
at
org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.executeExternalCompile(DefaultCompilerAdapter.java:591)
... 19 more
Caused by: java.io.IOException: CreateProcess error=206, The filename or
extension is too long
at java.lang.ProcessImpl.create(Native Method)
at java.lang.ProcessImpl.<init>(ProcessImpl.java:455)
at java.lang.ProcessImpl.start(ProcessImpl.java:151)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1040)
... 24 more
Total time: 2 minutes 5 seconds
============
On Linux, the Java files are actually compiled in to the destination directory
and the javac task completes without issue but the same changed compile
arguments are being returned when verbose output is turned on when using Ant
1.10.7+.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65539] javac task parses command line arguments incorrectly
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65539
--- Comment #4 from Sean Cleary <se...@ie.ibm.com> ---
Setting compiler="javac1.8" helped alright, it returned:
1. The correct output in the compilation arguments, the arguments look the
same as Ant 1.10.6 when using Ant 1.10.11.
2. The Java files compiled correctly into the destination directory.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65539] javac task parses command line arguments incorrectly
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65539
--- Comment #3 from Stefan Bodewig <bo...@apache.org> ---
does explicitly setting compiler="javac1.8" help?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65539] javac task parses command line arguments incorrectly
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65539
--- Comment #11 from Sean Cleary <se...@ie.ibm.com> ---
Thanks Stefan for looking at and fixing this and for answering questions around
how this functionality works. You've been very helpful.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65539] javac task parses command line arguments incorrectly
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65539
--- Comment #6 from Sean Cleary <se...@ie.ibm.com> ---
An echo statement was pushed in just before the javac task for the magic
property:
<echo message="build.compiler: ${build.compiler}"/>
and the output on Windows and Linux for Ant 1.10.11:
[echo] build.compiler: org.apache.tools.ant.taskdefs.compilers.JavacExternal
In case it helps, the actual 'build.compiler' property is being set in our
script to that value so as a test it was unset before the javac task and
compilation arguments returned correctly in the verbose output and the Java
files were compiled correctly.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65539] javac task parses command line arguments incorrectly
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65539
Stefan Bodewig <bo...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Stefan Bodewig <bo...@apache.org> ---
I modified both active branches of Ant, will be fixed in 1.10.12 and 1.9.17 (if
we ever release that).
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65539] javac task parses command line arguments incorrectly
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65539
--- Comment #8 from Sean Cleary <se...@ie.ibm.com> ---
If I'm honest, I've no idea why the build.compiler property is being set. It's
legacy code and there is no documentation validating the reason for setting the
property to this value.
Is this right on the build.compiler property?
1. If the build.compiler property is not set, the Javac task defaults to the
javac compiler provided by the JDK running Ant and with the fork property set
to true then by default it'll be set to extJavac.
2. Setting build.compiler to
org.apache.tools.ant.taskdefs.compilers.JavacExternal is the same as setting
the build.compiler property to extJavac.
If this is correct there is no advantage to setting the build.compiler property
explicitly or otherwise in this instance and we may be better off removing it
but at the very least we can use your workaround.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65539] javac task parses command line arguments incorrectly
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65539
--- Comment #7 from Stefan Bodewig <bo...@apache.org> ---
OK, thank you, I can confirm that setting build.compiler to a full class name
explicitly breaks the javac version detection in current master - which clearly
is a bug.
I'm not sure why you are setting the property explicitly, setting it to
extJavac probably has the same effect and should work for 1.10.6 and the later
releases if you need a workaround until we've got a fix released.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65539] javac task parses command line arguments incorrectly
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65539
--- Comment #5 from Stefan Bodewig <bo...@apache.org> ---
I was wrong about what I initially believed to be the problem, for some reason
your javac doesn't recognize it is running on Java 8 by itself.
Is there a property named "build.compiler" in your build? This is considered a
magic property by Ant and could change the outcome of its default detection
logic.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65539] javac task parses command line arguments incorrectly
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65539
Stefan Bodewig <bo...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |1.10.12
--- Comment #9 from Stefan Bodewig <bo...@apache.org> ---
Both of your points are correct. Actually there might be differences between
setting the property to extJavac or the classname - and the former should work
"better" even for 1.10.6 and earlier. For example Javac's isForkedJavac method
returns true for "extJavac" but false for the fully qualified classname unless
the fork attribute has been set to true explicitly (which looks like a bug as
well).
To me it looks as if your setup with setting build.compiler to the fully
qualified classname has only worked by accident in earlier releases. 1.10.7 has
reversed some decisions from "is this not JDK 1.1" to "is this JDK 1.2 or
later". In 1.10.6 setting build.compiler to a fully qualified classname results
in "this is not JDK 1.1" but also "this is not JDK 1.2 or later". It is not
even JDK 1.1 by the existing logic and so in 1.10.6 it has taken the "not 1.1"
branches that have now become "1.2 or later" branches and thus are no longer
chosen.
We'll fix things so that using the explicit classnames for the built-in
compiler adapters work the same as if their respective compiler short names
have been chosen, but in general using the full classname has never been
necessary and didn't really do what the initial authors thought it would do.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65539] javac task parses command line arguments incorrectly
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65539
--- Comment #2 from Sean Cleary <se...@ie.ibm.com> ---
On the Windows environment, the output is:
======
Detected Java version: 1.8 in: C:\IBM\WebSphere\AppServer\java\8.0\jre
Detected OS: Windows 10
======
On a Linux environment, the output is:
======
Detected Java version: 1.8 in: /opt/IBM/WebSphere/AppServer/java/8.0/jre
Detected OS: Linux
======
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65539] javac task parses command line arguments incorrectly
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65539
Sean Cleary <se...@ie.ibm.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fergal.gavin@ie.ibm.com,
| |seancleary@ie.ibm.com
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65539] javac task parses command line arguments incorrectly
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65539
--- Comment #1 from Stefan Bodewig <bo...@apache.org> ---
The changes indicate javac believes your compiler would be javac 1.1, which is
rather strange.
Pretty close to the start Ant will tell you which version of Java it has
detected in verbose output, it will look something like
Detected Java version: 1.8 in: /usr/lib/jvm/java-8-openjdk-amd64/jre
Detected OS: Linux
Can you please show what it looks like for you?
I think I can see the problem in DefaultCompilerAdapter but will need to add a
few tests - and it would be good if you could provide the info above anyway.
--
You are receiving this mail because:
You are the assignee for the bug.