Review request: JDK-8012453 (process) Runtime.exec(String) fails if command contains spaces [win]
martinrb at google.com
Tue Apr 23 16:45:23 UTC 2013
Random comments from a former maintainer:
I was never brave enough to tackle windows argument parsing or trying to
change legacy behavior.
I'm surprised you used LinkedList, which is almost never useful. Why not
Windows has arcane command line parsing rules, which are rather difficult
to get right, and I'm suspicious that you are not testing for all of them
(e.g. odd vs. even numbers of backslashes)
On Tue, Apr 23, 2013 at 6:22 AM, Alexey Utkin <alexey.utkin at oracle.com>wrote:
> Bug description:
> Here is the suggested trivial fix:
> Since the changes for JDK-8005942/JDK-8009463 that commands
> containing spaces cannot be used with Runtime.exec(String). Applications
> should really specify the command and its arguments using the Runtime.exec
> methods that take an array, or alternatively use ProcessBuilder as
> recommended since jdk1.5.
> Nevertheless we would like to minimize the impact for legacy Windows OS
> Java application. For application that works without the Security Manager,
> the "jdk.lang.Process.**allowAmbigousCommands" Java property could be
> defined programmatically or by program switch [-Djdk.lang.Process.**allowAmbigousCommands].
> Definition of the property returns old verification procedure for program
> name and program arguments with full risk of security vulnerabilities.
> For compatibility reason the case of quoted executable name in the
> Runtime.exec(String </j2se7/api/java/lang/String.**html>) was supported.
> If the Security Manager is installed, it is called twice for this case: for
> space-based paring result and result of extended parsing procedure that
> takes quotation into account. We do not guaranty the backward compatibility
> for any call with quoted executable name, but in general it works.
More information about the core-libs-dev