We have introduced strong jspawnhelper version checks with JDK-8325621. The original intent was to capture possible incompatibilities in jspawnhelper protocol that would silently break the process invocation.

It is now apparent there is the visible drawback to this: some Java services using distro-installed JDKs are running into version incompatibility checks after in-place (often unattended) update. We have now seen multiple reports by multiple customers that ran into jspawnhelper version checks. It does not help that jspawnhelper warnings are not bubbling up to the user-visible IOExceptions. I explored that part a bit (JDK-8352533), but it requires a much more comprehensive fix to cover all possible jspawnhelper failure modes.

Note this highlights the larger problem: overwriting the JDK while some application is using it can break the application in mysterious ways. jspawnhelper version checks detect this problem explicitly. Therefore, vendors still have to figure out how to do JDK upgrades safely: either putting updates in full-versioned paths to avoid overwrite, or prompting Java-based services to restart after overwriting JDK installation, or restart dependent services automatically, or block unattended upgrades while services are running.

But at this point, strong jspawnhelper version checks do more harm than good. Therefore, I believe the pragmatic approach would be to demote jspawnhelper version checks from being fatal to being informative, when the protocol detectably breaks, e.g. on incorrect number of arguments and/or incorrect FDs passed. This would still allow better debugging for jspawnhelper failures, while providing a smoother update experience, while distro vendors catch up.

To emphasize, this is not a bugfix, as version checks still a valid thing to do. This is merely a pragmatic concession to match the inconvenient, but hopefully only temporary broken state of the world.

This improvement is also targeted to be easily backportable, so we can catch up with update releases.