Hi Raffaello,
Runtime.exec and ProcessBuilder have been a challenge from the
beginning, on one hand
to have a reasonably cross-platform way to invoke processes and on the
other to accommodate
the platform differences, mostly on Windows due to the various command
line parsing decoding of
different applications and shells.
The idea is to provide greater consistency and a clear guidance about
how to invoke applications
while guarding against inadvertent mistakes that might refer to files or
other applications.
Assembling command lines from individual strings is error prone and
brittle especially
in cases where some of the arguments may be assembled from configuration
information,
external inputs, and the container or server environment.
Given the variations, the API should provide the application enough
control and responsibility
to customize the encoding to the target application, if it is needed,
but handle the usual cases
so it does not require developers to hand craft for each platform and
target application.
Ideally, the customization should be clearly visible in the API and be
clear and easy to review and audit.
Regards, Roger
On 2/24/22 4:22 PM, Raffaello Giulietti wrote:
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
