On Tue, 15 Dec 2020 22:47:16 GMT, Mandy Chung <mch...@openjdk.org> wrote:
>> As for `JRE_TOOL_MODULES`, I understand what you mean but it is at least >> kind of a "sibling" to the others. After all, we use these sets of modules >> together to form the set of modules for the JRE: >> >> JRE_MODULES += $(filter $(ALL_MODULES), $(BOOT_MODULES) \ >> $(PLATFORM_MODULES) $(JRE_TOOL_MODULES)) >> >> So given that `BOOT_MODULES` and `PLATFORM_MODULE` has a role to play here >> as well, I think it would be odd *not* to have `JRE_TOOL_MODULES` defined at >> the same place. > > `JRE_TOOL_MODULES` started with more than one modules in JDK 9: > > JRE_TOOL_MODULES += \ > jdk.jdwp.agent \ > jdk.pack \ > jdk.scripting.nashorn.shell \ > # > > Since only `jdk.jdwp.agent` one module is left for `JRE_TOOL_MODULES`, as you > are refactoring this file, I suggest to get rid of `JRE_TOOL_MODULES` and > explicitly name `jdk.jdwp.agent` in `JRE_MODULES`. Do you see a way to get rid of `DOCS_MODULES` but determine this set at build time? IIRC it was added for expediency for [JDK-8172312](https://bugs.openjdk.java.net/browse/JDK-8172312). This is the set of JDK (non-Java SE) modules (excluding `jdk.internal.*` modules and `jdk.unsupported` and also platform-specific modules). As for the conf file for module to class loader mapping, I actually like one single file `jdk-modules.conf` to enumerate all JDK modules. Currently it only defines the list of modules defined to boot and platform class loader but excludes any modules defined to application class loaders. I consider to enumerate all modules in this file and the build can verify if any module is missing. `module-sets-build.conf` is a bit awkward and I will give more thought on naming ideas. ------------- PR: https://git.openjdk.java.net/jdk/pull/1781
