On Thu, 14 Oct 2021 05:42:09 GMT, Denghui Dong <[email protected]> wrote:
> 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
To understand what is needed (namespacing, error handling, safety, lifecycle
etc.) and if this is actually useful for Java, I think you need to write 2-3
commands for a few popular frameworks, for example Spring.
If we can't come up with 5-10 commands where this functionality would solve
real problems users face, it's unlikely somebody will use it. It will just be a
maintenance burden in the JDK. Once an API is added, it's hard to remove.
The scope of this seem to be JEP level.
(JFR is not a valid use case, since we don't want to add a dependency on
annotation classes in the jdk.jcmd module).
-------------
PR: https://git.openjdk.java.net/jdk/pull/5938
