On Sat, 28 Oct 2023 06:37:00 GMT, Alan Bateman <al...@openjdk.org> wrote:

>> The `ArchivedModuleGraph.java` wasn't changed. So if `-m` is not specified, 
>> the `archivedModuleGraph` is non-null; if `-m` is specified, the 
>> `archivedModuleGraph` is null.
>> So running `java -version`, the archivedModuleGraph is non-null, but the 
>> module m won't be loaded from the archive. I'm seeing the following log 
>> output:
>> 
>> `[0.220s][debug][module     ] define_module(): creation of module: m, 
>> version: null, location: jrt:/m, loader data: 0x00007f201819dd60 for 
>> instance a 
>> 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x000000011f010500}, 
>> package #: 1`
>
>> The `ArchivedModuleGraph.java` wasn't changed. So if `-m` is not specified, 
>> the `archivedModuleGraph` is non-null; if `-m` is specified, the 
>> `archivedModuleGraph` is null. So running `java -version`, the 
>> archivedModuleGraph is non-null, but the module m won't be loaded from the 
>> archive.
> 
> Right, but ArchivedModuleGraph provides the initial value for 
> hasIncubatorModules, hasSplitPackages, ... This is why `java -version` 
> confusingly prints a warning that an incubator module has been resolved. 
> We've had archiving of the module graph (configuration) for a long time but 
> it's only been for the case where the initial module is the unnamed module. I 
> think archiving of the boot layer for the case where the initial module is a 
> named module means we have to re-visit ArchivedModuleGraph. I think 
> ArchivedModuleGraph.get has to return null when the archive doesn't match the 
> mainModule. Part of it wonder if we should remove ArchivedModuleGraph, 
> support archiving of the boot layer only.

I've added the following field in `ArchivedModuleGraph` so that the `get(String 
mainModuleName)` will check the `mainModule` before returning 
`archivedModuleGraph`.
`private static String mainModule;`
The `mainModule` field is also added in `heapShared.cpp` so that it is stored 
in the archive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1377099846

Reply via email to