RFR: 8275259: Add support for Java level DCmd [v2]

[Denghui Dong]

On Fri, 15 Oct 2021 10:58:29 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> (RFC: https://mail.openjdk.java.net/pipermail/serviceability-dev/2021-October/039796.html)
>> 
>> I proposed to extend DCmd to allow Java developers to customize their own diagnostic commands last week.
>> 
>> At present, I have implemented a preliminary version.
>> 
>> In the current implementation, I provided some simple APIs in the Java layer (under sun.management.cmd) for defining and registering commands.
>> 
>> - Executable interface
>>   Java diagnostic commands need to implement this interface, the interface only contains a simple method:
>> 
>>     /**
>>      * @param output the output when this executable is running
>>      */
>>     void execute(PrintWriter output);
>> 
>> 
>> - Add two annotations (@Command and @Parameter) to describe the command meta info
>> 
>> - Use Factory API to register command, the following forms are supported
>> 
>> @Command(name = "My.Echo", description = "Echo description")
>> class Echo implements Executable {
>> 
>>     @Parameter(name = "text", ordinal=0, isMandatory = true)
>>     String text;
>> 
>>     @Parameter(name = "repeat", isMandatory = true, defaultValue = "1")
>>     int repeat;
>> 
>>     @Override
>>     public void execute(PrintWriter out) {
>>         for (int i = 0 ; i < repeat; i++) {
>>             out.println(text);
>>         }
>>     }
>> }
>> 
>> Factory.register(Echo.class);
>> 
>> 
>> 
>> Factory.register("My.Date", output -> {
>>     output.println(new Date());
>> });
>> 
>> 
>> - When the command is running, the VM will call `Executor.executeCommand` to execute the command. In the implementation of Executor, I introduced a simple timeout mechanism to prevent the command channel from being blocked.
>> 
>> At the VM layer, I extended the existing DCmd framework(implemented JavaDCmd and JavaDCmdFactoryImpl) to be compatible with existing functions (jmx, help, etc.).
>> 
>> In terms of security, considering that the SecurityManager will be deprecated, there are not too many considerations for the time being.
>> 
>> Any input is appreciated.
>> 
>> Thanks,
>> Denghui
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   print argument key if not found

Thanks for the commands, the following is my thought.

Compared with the user's own implementation of a DiagnosticCommandMBean, the main benefits of this extension are:

Users can directly use `jcmd` to invoke (better user experience, of course, users can also invoke through a jmx client like jconsole), and use `jcmd pid help` to list all VM commands and user-defined commands. And all parameters or options are pre-parsed, making the implementation of the command simpler and focusing on their own logic. 

I am not an expert in the security field, but I feel that implementing a DiagnosticCommandMBean by the users does not seem to be more secure than the method in the proposal. I mean the users can still do whatever they want.

Just like Chris said, it seems that not many people are interested in this proposal. I plan to close this PR first.
If there are any others who want this in place, we can continue to discuss it in the RFC thread of this proposal.

Denghui,
Thanks

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

PR: https://git.openjdk.java.net/jdk/pull/5938