On Thu, 2 Nov 2023 07:41:27 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> Tool modules can be created via `jmod --main-class` option such that >> `ModuleMainClass` attribute will be added in `module-info.class` and the >> module's main class can be launched via `java -m <module-name>` without >> specifying the name of the main class. >> >> In addition, for modules with `ModuleMainClass` attribute, jlink will >> pre-resolve the module graph such that when such module is launched at >> runtime (without `--add-modules` or `--limit-modules` option), the runtime >> can skip the module resolution and speed up the startup time. >> >> This PR extends the build system to allow a module to specify the main class >> under `make/modules/$MODULE/Jmod.gmk` file. Also JDK tools with a single >> entry point (or a primary entry point) are candidates to add >> `ModuleMainClass` attribute in `module-info.class` to benefit from the jlink >> optimization. For example, `java -m jdk.jpackage` will be launched using >> the pre-resolved module graph. >> >> Verified manually by running `java -m $MODULE` on the modules with main >> class. > > make/modules/jdk.jdi/Jmod.gmk line 26: > >> 24: # >> 25: >> 26: JMOD_FLAGS_main_class := --main-class com.sun.tools.example.debug.tty.TTY > > I'm not sure about this one. Every few years there is a suggestion to > deprecate or remove jdb. It's the example debugger from the original JPDA > effort in the JDK 1.2 timeframe and hasn't really developed much since then. > The main reason is stays around is that it is needed by our tests, and some > people say it's useful to have something in production environments where the > main stream debuggers can't go. I'm not opposed to "java -m jdk.jdi", it's > just that this is a legacy/example tool that isn't the main focus of the > jdk.jdi module. I can share the same concern. I will take this out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16463#discussion_r1380394808