RFR: 8318913: The module-infos for --release data do not contain pre-set versions

Magnus Ihse Bursie ihse at openjdk.org
Wed Nov 8 16:35:01 UTC 2023


On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda <jlahoda at 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.

make/Main.gmk line 974:

> 972:   # The ct.sym generation uses all the moduleinfos as input
> 973:   jdk.compiler-gendata: $(GENSRC_MODULEINFO_TARGETS) $(JAVA_TARGETS)
> 974:   ifeq ($(CREATE_BUILDJDK), true)

I think I've sorted this out. The `buildjdk` COMPILER resolves to the newly built compiler if we do not have CREATE_BUILDJDK (which really means "USE_BUILDJDK"), and since they are built by jdk.compiler-launchers, we need to make that target first. Otoh, if we have a buildjdk, we're fine, unless we're in the process of creating a buildjdk, then we need to make sure we got the buildjdk first. Is this a proper reading of this?
(I think this part could do with some comments, since the logic here is not exactly crystal clear...)

But why would we even create ct-sym when creating a buildjdk? That seems like just a waste of time?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16400#discussion_r1386902562


More information about the build-dev mailing list