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

Reply via email to