This came up in the context of #753, where it is relevant to launch a multi-release application on specific JVMs, to test variant behavior on those JVMs: when launching uses an execution environment, the user may think they selected version X where in fact a JVM Y (Y>X) is used. Thus the intention of testing behavior for variant X is not fulfilled.
In case a user is not sharply aware of the difference between selecting an EE vs JRE they will be surprised by the result.
Hence I suggest to issue a warning when the selected EE does not perfectly match any known physical JRE.
This warning is relevant in any multi-release setting. But even without any multi-release configuration there is no 100% guarantee that a higher JVM matches the exact behavior of the selected version; think of any modules / classes / methods that are effectively removed from a JVM at a higher version, whereas the selected lower version would still have it.
This came up in the context of #753, where it is relevant to launch a multi-release application on specific JVMs, to test variant behavior on those JVMs: when launching uses an execution environment, the user may think they selected version X where in fact a JVM Y (Y>X) is used. Thus the intention of testing behavior for variant X is not fulfilled.
In case a user is not sharply aware of the difference between selecting an EE vs JRE they will be surprised by the result.
Hence I suggest to issue a warning when the selected EE does not perfectly match any known physical JRE.
This warning is relevant in any multi-release setting. But even without any multi-release configuration there is no 100% guarantee that a higher JVM matches the exact behavior of the selected version; think of any modules / classes / methods that are effectively removed from a JVM at a higher version, whereas the selected lower version would still have it.