P5
A DESCRIPTION OF THE REQUEST :
the Runtime.exec methods exist in otherwise duplicate forms that take a "String command" and that take a "String[] cmdarray". the former were provided as a "convenience" but seem to serve mainly to trip up exactly the beginners who'd be tempted to use them. the superior String[] forms already exist, and we should encourage users to switch to them.
the two common failure modes are:
1. Windows systems' binaries are often located in "C:\Program Files\", meaning correct quoting is required to use the "simpler" (program + " " + argument) instead of (new String[] { program, argument }).
2. Mac and Windows users often have spaces in their filenames. this is equivalent to the first failure mode, but now the argument needs quoting rather than the program. (i've seen uses that quoted only one of the two, as well as those that quote neither.)
these problems alone account for a surprising amount of the traffic on some mailing lists (Apple's java-dev list being the one i'm most familiar with). many people's "porting" trouble comes down to little more than "use the form of Runtime.exec you should have used in the first place, instead of the dangerous "convenience" form.)
the more difficult problem is:
3. the breaking up of the "String command" doesn't follow Unix rules or Windows rules, confusing both sides. From the JavaDoc:
More precisely, the command string is broken into tokens using a StringTokenizer created by the call new StringTokenizer(command) with no further modification of the character categories. The tokens produced by the tokenizer are then placed in the new string array cmdarray, in the same order.
not only is this behavior strange, it's not obvious that it can be sensibly fixed. a good job of imitating Windows could probably be done, but that would probably lead to lots of code that only works on Windows. on the Unix side, it's not obvious which shell should be copied, or that such a thing is even a good idea.
StringTokenizer itself, though not deprecated, is described thus: "StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code."
JUSTIFICATION :
beginners invariably go for the less robust, less portable, variant.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
the String variants should be deprecated and the String[] variants' use more strongly encouraged.
ACTUAL -
the single-argument String variant is mentioned first in the JavaDoc, with no explanation as to why it's a liability. from the beginner's point of view, the String[] variant just looks like more hassle for no benefit.
the Runtime.exec methods exist in otherwise duplicate forms that take a "String command" and that take a "String[] cmdarray". the former were provided as a "convenience" but seem to serve mainly to trip up exactly the beginners who'd be tempted to use them. the superior String[] forms already exist, and we should encourage users to switch to them.
the two common failure modes are:
1. Windows systems' binaries are often located in "C:\Program Files\", meaning correct quoting is required to use the "simpler" (program + " " + argument) instead of (new String[] { program, argument }).
2. Mac and Windows users often have spaces in their filenames. this is equivalent to the first failure mode, but now the argument needs quoting rather than the program. (i've seen uses that quoted only one of the two, as well as those that quote neither.)
these problems alone account for a surprising amount of the traffic on some mailing lists (Apple's java-dev list being the one i'm most familiar with). many people's "porting" trouble comes down to little more than "use the form of Runtime.exec you should have used in the first place, instead of the dangerous "convenience" form.)
the more difficult problem is:
3. the breaking up of the "String command" doesn't follow Unix rules or Windows rules, confusing both sides. From the JavaDoc:
More precisely, the command string is broken into tokens using a StringTokenizer created by the call new StringTokenizer(command) with no further modification of the character categories. The tokens produced by the tokenizer are then placed in the new string array cmdarray, in the same order.
not only is this behavior strange, it's not obvious that it can be sensibly fixed. a good job of imitating Windows could probably be done, but that would probably lead to lots of code that only works on Windows. on the Unix side, it's not obvious which shell should be copied, or that such a thing is even a good idea.
StringTokenizer itself, though not deprecated, is described thus: "StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code."
JUSTIFICATION :
beginners invariably go for the less robust, less portable, variant.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
the String variants should be deprecated and the String[] variants' use more strongly encouraged.
ACTUAL -
the single-argument String variant is mentioned first in the JavaDoc, with no explanation as to why it's a liability. from the beginner's point of view, the String[] variant just looks like more hassle for no benefit.
- duplicates
-
JDK-7032100 Runtime.exec is unable to deal with paramters containing more than two blanks
-
- Closed
-