jlink checks the version of the java.base module when linking to ensure that it is compatible with the current runtime. jlink plugins are deeply tied to JDK internals so you can't run jlink on JDK X and create a run-time with modules from JDK Y. 

At this time the version check fails if the java.base module isn't the same feature + interim version as the JDK running jlink. This check is sufficient to prevent jlink running on one feature release from creating a run-time image for a different feature release. It doesn't prevent using jlink on say JDK N.0.1 and using to produce a run-time image for JDK N.0.2. This case will work until there is a change to something in java.base or the jlink plugin that breaks this cross linking combination. The other scenario that is more brittle is running jlink on JDK N.0.1 from vendor X and attempting it to use to create a JDK N.0.1 with modules from vendor Y. If the two builds aren't from the exact same bits then there is no guarantee that it will produce a working JDK.

We need to re-examine the version check used for jlink cross linking. One possibility is extending the existing check to include other version properties, the class file API can be used to get these from the target's VersionProps class file. Another possibility is the git hash to ensure the builds came from the same source but this assumes there is a repo at build time.