On Fri, 9 Jan 2026 15:40:30 GMT, Roger Riggs <[email protected]> wrote:
> The jimage versions number are only significant within the tool and > implementation. If the version numbers were synchronized to the JDK version, > (as we do with class file versions, CDS archives, etc.) it would be > straight-forward for the message to be specific about what version of jimage > is needed for the jimage. While that's true, it also incurs additional maintenance to ensure it's not accidentally left as the wrong value, and it would mean that in the vast majority of cases where no file structure had changed, the tool would now not work (possibly breaking existing users in unnecessary ways). An alternate approach would be to store the JDK version (as a string) at which the file was made, but not use it for the check. This way you only need it when the check fails, but can provide a precise version that would work. As Alan points out, this is really an internal tool and doesn't offer comprehensive error messages today, so it might not be worth a lot of effort to make highly detailed error messages for what should be a tiny number of advanced users. I do think some explanation is needed however, since this is a new type of failure mode which couldn't previously occur and might otherwise stump the tiny number of people it could affect. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28456#issuecomment-3738480540
