jspawnhelper is invoked by JDK ProcessBuilder/Runtime.exec to invoke a process with posix_spawn. There is the internal protocol between JDK invocation code and jspawnhelper, which changes sometimes, see e.g. JDK-8310265.

We expect that only JDK invokes jspawnhelper. But there are two corner cases.

First, someone could call jspawnhelper directly. There is a warning message printed in some cases, for example when jspawnhelper is invoked without arguments: "This command is not for general use and should only be run as the result of a call to ProcessBuilder.start() or Runtime.exec() in a java application". Quick googling shows that projects still ignore this warning. See for example Zimbra (https://wiki.zimbra.com/wiki/Jspawnhelper): "One example of legitimate use [sic! -Aleksey] of jspawnhelper is by zmprov, the command line utility to provision accounts on Zimbra."

Second, there is a minuscule chance of system misconfiguration when jspawnhelper from another JDK would be executed instead of one shipping with invoking JDK. Current code figures out the jspawnhelper path from `java.home` property, which looks safe-ish, but it would be even better to make sure. There is also the report from Ubuntu: https://bugs.launchpad.net/ubuntu/+source/openjdk-17/+bug/2055280 -- that unattended upgrade replaced the JDK under the running JVM, which effectively replaced the old jspawnhelper with an incompatible one. This is arguably the upgrade process problem, as JDK is not guaranteed to work when its contents are overwritten, but we want to catch that error consistently.

I think we can make jspawnhelper checks a bit better by handshaking on explicit JDK/VM version. Something like `VERSION_STRING` already defined by the build system can be compiled into the `jspawnhelper` and checked against.