On Thu, 9 Nov 2023 10:55:06 GMT, Jan Lahoda <jlah...@openjdk.org> wrote:
>> Consider a simple module, like: >> >> module test {} >> >> >> And compile it with JDK 22 and JDK 21 using: >> javac --release 21 >> >> The results of the compilations will differ: when compiling with JDK 21, the >> mandated java.base dependency will get a version, possibly like >> "21-internal". When compiling with JDK 22, the version of the java.base >> dependency will be empty. >> >> This is a) because `module-info.class`es in `ct.sym` do not have any module >> version set; b) for JDK N, `--release N` is not using `ct.sym`, but rather >> `lib/modules`, which may contain a range of version specifiers. >> >> This patch does two changes: >> a) tweaks the `module-info.class`es in `ct.sym`, so that they contain a >> simple version. For `--release N`, the version is `N`. >> b) tweaks the whole build so that `ct.sym` is used always for `--release`, a >> `lib/modules` is never used. I.e. the appropriate classfiles are copied into >> `ct.sym`. This not only allows for a general approach to module versions, >> but simplifies the `--release` handling in javac, and should enable future >> improvements. This is, however, a relatively big change. >> >> The use of `lib/modules` for `--release <current>` was made to improve build >> performance, but the build has been updated since this has been introduced, >> so the slowdown caused by rebuilding `ct.sym` should be much lower now. >> >> With these changes, compiling with `--release N` should record the same >> dependency versions in `module-info` on JDK N and JDK N + 1. > > Thanks for the comments so far. I have locally added the pre-release text to > the module versions and merged recent Erik's changes. I'll push the updated > version in a few hours. @lahodaj, should this change get a CSR to cover the behavioral changes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16400#issuecomment-1804293641