JDK-8030961 : [launcher] java tools requires the whole argument containing spaces to be quoted
  • Type: Bug
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: windows_7
  • CPU: x86
  • Submitted: 2013-12-23
  • Updated: 2017-04-13
  • Resolved: 2014-03-18
Related Reports
Duplicate :  
JDK-8035418 - Not able to parse command line arguments when path contains multiple quotes
Relates :  
JDK-7146424 - Wildcard expansion for single entry classpath
Relates :  
JDK-8031408 - [docs] Release note JDK-8030961
Description
in 1.8.0-ea javac no longer works when typing c:\"Program Files"\Java\jdk1.8.0\bin\javac or even c:\"Progra~1"\Java\jdk1.8.0\bin\javac (they find javac but then javac is doing strange things looking at the entire command line instead of just following the javac command).

javac does not work correctly with the incorrect messages:

c:\Temp\test>C:\"Program Files"\Java\jdk1.8.0\bin\javac *.java
javac: file not found: Files\Java\jdk1.8.0\bin\javac  *.java

Usage: javac <options> <source files>
use -help for a list of possible options

 

c:\Temp\test>C:\"Progra~1"\Java\jdk1.8.0\bin\javac *.java
Usage: javac <options> <source files>

where possible options include:
  -g                         Generate all debugging info
  -g:none                    Generate no debugging info
  -g:{lines,vars,source}     Generate only some debugging info
  -nowarn                    Generate no warnings
  -verbose                   Output messages about what the compiler is doing
  -deprecation               Output source locations where deprecated APIs are used

In the two examples above it is saying that the usage is incorrect, which it is not, and in fact depending on the command line both of which are calling javac *.java it gives two different messages of which both are incorrect. 

Have been using java for about 16 years and never seen this problem before. Need change my path to include the java bin directory and use javac by itself to get it to work.
Comments
We will not fix this.
18-03-2014
Priority justification: Impact: Medium, inconvenient Likelhood: Medium, intermittent. Workaround: Low, quote the entire commenad ILW = MML => P4
27-01-2014
I don't not think this is a bug as how an application handles args, in particular argv[0], is up to the application. Maybe...maybe...this can be an RFE. I find the handling of argv[0] to differ from app to app. The apps themselves start (the command processor figures this out), but then all args are passed to the application and reparsed and sometimes aregv[0] is the command and sometimes it's mangled. Some apps treat argv[0] different from argv[1]...argv[n] but this is not specified. In fact, some MS apps can handle the intermittent quoting of strings and some can't. The C++ spec (noted above) seems to refer only to args starting at argv[1] so that argv[0] is left out of the discussion. Examples: c:\"Program Files"\"Microsoft Office"\Office14\EXCEL.EXE c:\docs\somespreadsheet.xls initially shows an error dialog about not being able to find 'Files"\"Microsoft.xlsx' and suggest user check the spelling. However, it you click OK, it opens the file. c:\"Program Files"\"Windows Media Player"\wmplayer.exe c:\music\somesong.mp3 starts media player but does not find the file. Open Office is interesting in that it mangles the command line given to it issuing several error dialogs before actually opening the file. Given c:\"Program Files"\"OpenOffice.org 3"\program\soffice.exe c:\docs\somespreadsheet.ods, It shows error dialog: C:\Program Files\OpenOffice.org 3\program\Program FileOpenOffice.org 3\program\soffice does not exist and after clicking "OK" button, another mangle form of an error message, then it starts and shows another mangled error message, but then it loads the file, then shows another error dialog! In all cases, quoting the entire command itself and also quoting entirely any arguments with spaces works. That would seem to be the suggested usage and I think that it what java launchers do.
03-01-2014
I would like to close this bug, here are the reasons: 1. The java windows command line parser is working according to the Windows command line parsing specification here: http://msdn.microsoft.com/en-us/library/vstudio/17w5ykft%28v=vs.110%29.aspx 2. Modifying the existing command line parser to accommodate MS behavior, (btw. which is a bug, according to the above specification). to parse argv[0] is risky, and will cause regressions and will require re-writing the logic and complicate java launcher implementation. 3. Easy and correct solutions exist: a. quote the entire argument ex: "c:\Program Files\jdk\bin\java.exe", this is exactly the way the MS-DOS command shell (cmd.exe) quotes the argument, try it for yourself. b. use back-slash to escape the double-quote, ex: c:\\"Program Files\"\jdk\bin\java.exe c. use short filenames ie. 8.3 format instead of the long spaced names ex: c:\Progra~1\jdk\bin\java.exe
03-01-2014
8-defer-SQE-OK: This is a regression but due to change in MS's setarg.obj when MSDN compiler was upgraded. There are 2 workarounds, quote entire string or possibly use windows short names ( as shown by 'dir /x' on windows ).
02-01-2014
Release team: Approved for deferral.
02-01-2014
The trouble is the first back-slash "c:\" is a drive-specification, but the cmdline parser treats it as a literal back-slash according to the MSDN specification here: http://msdn.microsoft.com/en-us/library/windows/desktop/17w5ykft%28v=vs.110%29.aspx The specification does not provide clarity on the drive specification itself, the java command line parsing is consistent with the behavior of VisualStudio CRT argument parsing setargv.cpp. c:\WC>c:\"A B"\Foo.exe c:\"A B" argv[0]=c:\A B\Foo.exe argv[1]=c:"A argv[2]=B Solution: *do not place a quote directly after a drive specifier such as c:\, placing the quotes elsewhere does the trick, if you still want to use the quote after the drive specifier, then use c:\\"Program Files\"\bin......
30-12-2013
Reproduced with b121, noted the quote only at "Program Files" or "Progra~1" causing the problem. To work around, quote the whole "C:\Program Files\Java\jdk1.8.0\bin\javac" or don't quote "Progra~1".
30-12-2013