This has the undesirable effect of potentially attempting to kill a process with PID -1

Do you know what causes that? Because surely if the path is empty from some other mistake that still shouldn't happen. Feels like this fix is targeting the wrong part of the code, or at least the underlying problem should also be fixed in addition to this.

Seems to be something else, actually. On my machine, the launcher tries to spawn 1490 Java checkers, and a timeout happened with a non-empty path. It's possible that the launcher is just spawning too many processes and hitting some limit.
I also tried checking whether a candidate exists and is executable with FS::ResolveExecutable, which cut the number of checkers down to just 9, and also dramatically sped up the auto-detection. Assuming it will work as intended on Windows, skipping non-executable paths could resolve this issue for the vast majority of users.
Would you like me to add that check to this PR, or would you prefer a separate PR?

Would you like me to add that check to this PR, or would you prefer a separate PR?

Would prefer as another commit to this PR.

On second thought, this issue only really affects the Linux Java detection code, which blindly considers an excessive number of locations instead of checking a more limited set like on Windows and macOS.
Skipping non-executable paths in JavaListLoadTask::executeTask after JavaUtils::FindJavaPaths seems like a simpler solution, at the cost of (temporarily) allocating a QList<QString> with thousands of elements. Alternatively, the Linux code could filter out non-executable paths before adding them to the list.
What do you think?

Looking at strace output, I could observe a failed clone(flags=CLONE_PIDFD|SIGCHLD, ...) followed by thousands of failed pipe2() syscalls, all failing with EMFILE (Too many open files), which sounds like it's trying (and failing) to keep track of thousands of processes.
Whenever the auto-detection hangs (and eventually hits the timeout), I could also see that "Java checker has failed to start." is only logged 1480 times instead of the expected 1481, which suggests that the launcher tries to spawn so many processes that even Qt (5) struggles to keep track of failure.

@byte-chan Why is it expected to fail 1481 times? Also should I merge the PR now? Idk whether your look into the issue with strace made you think of changing anything with it.

Current develop scans several directories on Linux and blindly assumes there might be a Java executable, which adds up to 1490 candidates on my machine, 1481 of which don't even exist. The second commit cuts that down to just 9 by checking whether those candidates are actually executable instead of spawning a process to find out. In the end, the issue was the launcher spawning so many processes at once that Qt fell over, so not doing that would help.

Yes, the PR should be good to merge now.