On Wed, 18 Mar 2026 19:52:50 GMT, Roger Riggs <[email protected]> wrote:
>> test/jdk/java/lang/ProcessBuilder/Basic.java line 710: >> >>> 708: setFileContents(trueExe, "#!/bin/true\n"); >>> 709: trueExe.setExecutable(true); >>> 710: } >> >> I wonder what the benefit is of this triple safety here (use OS true, use >> our own true, use shell script). >> >> Is there any benefit of one over the other? And would finding BasicTrue ever >> fail? And if it failed, would that not be a test setup error? The last >> condition could hide such an error indefinitly. >> >> I'd probably just use OS true, then BasicTrue. Or even just BasicTrue >> outright. Unless you want to test PATH resolution for OS binaries? But that >> should then be a separate test, since whether or not it gets executed >> depends on whether the OS happens to use multi-call bins. > > The change is minimally changing the test environment, since testing some of > the lesser known Linux variants are not easy to come by. > Using the OS true/false is a non-starter on Ubuntu 25-10 and on Musl due to > the multi-exe construction on those platforms. > The identified binary must be able to be copied to different directories and > different names and still have the correct exit status. > > Settling back to using only the BasicTrue/BasicFalse binaries is likely to be > stable after potential failures in porting to the other platforms. Okay. I would have thought that you don't need that many different Linux variants if you roll your own solution: don't rely on system true+false, and don't rely on the installed shell. If you just compile your own program and run it, you minimize the dependencies on the target OS - the only thing you depend on then is the kernel and libc. One thought I had was do we even need two programs, true and false? You could just provide a single program (the self-written variant) that returns maybe something more exciting than 0 or 1. You could even hand in the exit code as an argument to the program. Lets call it "mirror", and "mirror 26" returns 26 as exit code. Then, use a random input argument and check that this random number is the exit code of the child process. That way, you can be sure the PATH resolution really got your mirror program, and you don't need to juggle two programs around. This is just an idea. If you want to reduce the changes in this PR, I am fine with your current solution. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30150#discussion_r2957963266
