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

[Erik Joelsson]

On Wed, 8 Nov 2023 16:31:47 GMT, Magnus Ihse Bursie <ihse 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?

If cross compiling, a BUILD_JDK can either be supplied by configure, or be built dynamically for the build platform. When not cross compiling, it's created implicitly by the build. There are two variables from configure that describe this:

`CREATE_BUILDJDK` : true if we are cross compiling and need to explicitly create a build jdk for the build platform.
`EXTERNAL_BUILDJDK`: true if a prebuilt build jdk has been supplied to configure.

When CREATE_BUILDJDK is true, there is also the variable `CREATING_BUILDJDK` that is set men `Main.gmk` is called recursively to actually create a build jdk for the build platform.

There are more comments for these cases around the jmod targets. However, while writing this I realize that we are missing a conditional on `EXTERNAL_BUILDJDK` being false.

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

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