On Thu, 14 Oct 2021 05:42:09 GMT, Denghui Dong <dd...@openjdk.org> 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 Hi Thomas, > Hi, > > Interesting proposal. I have some questions. > > * Will hanging java user code block the attach listener thread? If yes, how > would you solve that? In my current implementation, I use a simple timeout mechanism to solve this problem. Create a Thread to run the command, and use `java.util.concurrent.Future#get(long, java.util.concurrent.TimeUnit)` to get the result. For more details please refer to Executor.java. > * Will this require changes to the jcmd client, or will this work with any > jcmd client, up- and downward the JDK versions? (the nice thing about jcmd is > that all the logic resides at the hotspot and I can use any client to talk to > any hotspot) > At present, I only extend the DCMD framework and do not modify the code of jcmd. So it works with any jcmd client and jmx client, up and downward JDK versions I think. > Cheers, Thomas > > P.S. I think it may be worthwhile to discuss this on the serviceability-dev > mailing list first. Denghui Hi Erik, > 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). Thanks for the comments. I will investigate whether there is a scenario to apply this extension in the current mainstream framework. Denghui ------------- PR: https://git.openjdk.java.net/jdk/pull/5938