On Sat, 21 Oct 2023 07:42:06 GMT, Alan Bateman <al...@openjdk.org> wrote:
>>> Yes, because of the following code further up in the same method: >> >> I think what you are actually doing here is supporting archiving of the boot >> layer when the main module transitively depends on an incubator module. We >> might have to add more tests in this area as it doesn't look like this >> scenario is tested, at least not with CDS. > >> > Yes, because of the following code further up in the same method: >> >> I think what you are actually doing here is supporting archiving of the boot >> layer when the main module transitively depends on an incubator module. We >> might have to add more tests in this area as it doesn't look like this >> scenario is tested, at least not with CDS. > > Just to add to this. The effect of this change is that a warning won't be > emitted if you archive with a boot layer that contains a main module and an > incubator module, e.g. main requires jdk.incubator.vector. In other words, > `java -Xshare:off -m main` will print the expected warning, `java -Xshare:on > -m main` will not. Another effect of the change to note is that incubator modules will now resolved by default when the initial module is the unnamed module. More explicitly, if you jlink to create a run-time image that contains a main module and an incubator module then `java -Xshare:off -version` will not resolve the incubator moduls (correct behaviour) but `java -Xshare:on` will resolve incubator modules (wrong behavior). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1367685991
