Proposed JEP: Safer Process Launch by ProcessBuilder and Runtime.exec

Raffaello Giulietti raffaello.giulietti at gmail.com
Thu Feb 24 21:22:49 UTC 2022


Hi,

on Windows, the mechanism to launch a new program is for the parent to 
call CreateProcess(). This function accepts, among others parameters, a 
lpApplicationName string and a lpCommandLine string. There's a *single* 
lpCommandLine that encodes all the arguments to pass to the new program.

The exact encoding of the arguments in the command line is imposed by 
how the *new* program parses (decodes) the command line to get its 
constituent parts. There are no fixed rules on how this happens. There 
are some more or less well documented rules for some runtimes (e.g., the 
C/C++ runtime) or for some specific programs (e.g., cmd.exe., 
wscript.exe). In general, however, a program can decode in any way it 
deems useful.

Because the encoding is dictated by the target program's decoding, and 
because the latter is really arbitrary, there's no safe, universal 
procedure to encode a list of string arguments to a single command line 
string. It is only when the decoding rules in the target program are 
known that encoding in the parent becomes feasible.

Thus, it might be more useful on Windows platforms to avoid the API 
points that expose List<String> or String[] for the arguments to the 
target program and use the ones that accept a single String, instead. 
The client of those API points would then have to deal with the encoding 
specific for that program. This is a better match with the underlying OS 
mechanism, namely CreateProcess(), which accepts a single, already 
encoded string.

In addition, to assist programmers unfamiliar with specific encodings, 
widely used specific encoders (e.g., for the C/C++ runtime [1], for 
cmd.exe, etc.) can be implemented separately.


Greetings
Raffaello

----

[1] 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-February/086105.html


More information about the core-libs-dev mailing list