On Tue, 24 Aug 2021 19:15:56 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> test/jdk/java/lang/ProcessBuilder/Basic.java line 2635:
>>
>>> 2633: List<String> childArgs = null;
>>> 2634: Path sleepExe = TEST_NATIVEPATH.resolve("sleepmillis");
>>> 2635: if (sleepExe.toFile().canExecute()) {
>>
>> Why is the fallback necessary? Other test cases such as
>> test/jdk/tools/launcher/JliLaunchTest.java do not have such a fallback.
>>
>> Also, I noticed that JliLaunchTest does something like this:
>>
>>
>> Path launcher = Paths.get(System.getProperty("test.nativepath"),
>> "JliLaunchTest" + (Platform.isWindows() ? ".exe" : ""));
>>
>>
>> but test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
>> doesn't add ".exe", so it may not be necessary.
>
> See above, the java Child is more portable and lower maintenance.
> Windows looks for xxx.exe if xxx is not found.
How about adding a comment to explain why the fallback is necessary?
Also, if `jtreg -nativepath:xxx` is specified, but there's no xxx/sleepmillis,
or xxx/sleepmillis is not executable, that should be a setup error (or a bug in
the test itself). E.g., if we are testing inside mach5, we should always
execute the native program, and should not silently fallback to the java Child
program. Otherwise, setup problems in mach5 might bring us back to the
mysterious intermittent failure.
(The current version of the code is buggy on Windows and will always silently
fall back to Child because the executable is named "sleepmillis.exe", not
"sleepmillis").
-------------
PR: https://git.openjdk.java.net/jdk/pull/5239
