On 11/9/21 2:07 PM, Chris Plummer wrote:
On 10/14/21 12:38 AM, David Holmes wrote:
On 14/10/2021 5:14 pm, Denghui Dong wrote:
On Thu, 14 Oct 2021 06:43:20 GMT, David Holmes
<david.hol...@oracle.com> wrote:
I'm not sure exactly where this API would need to go. IIUC jcmd
doesn't
exist at the Java level it is just a tool, so introducing an API to
interact with it seems problematic to me.
IMO, `jcmd` is a client of `dcmd`, the user also can use JMX to
execute `dcmd`, this means there already are Java APIs interact with
`dcmd`.
Ah right - so you're really looking at extending the capabilities of
the DiagnosticCommandMBean to add a way to register a Java diagnostic
command.
David
Just reviewing some previous emails and noticed this one since I
recently looked into the JMX support. JMX supports a rather generic
concept of executing diagnostics commands (there is no actual
reference to "dcmds"). See com.sun.management.DiagnosticCommandMBean
and its superinterface javax.management.DynamicMBean:
https://docs.oracle.com/en/java/javase/15/docs/api/jdk.management/com/sun/management/DiagnosticCommandMBean.html
https://docs.oracle.com/en/java/javase/15/docs/api/java.management/javax/management/DynamicMBean.html
DynamicMBean provides the invoke() interface, which when used on a
DiagnosticCommandMBean will invoke the specified diagnostic command.
It says nothing about how diagnostic commands are implemented or
registered with the jvm. That I assume would be JVM implementation
dependent.
Ah right - so you're really looking at extending the capabilities of
the DiagnosticCommandMBean to add a way to register a Java diagnostic
command.
Yes to "add a way to register a Java diagnostic command", but the new
API will not involve DiagnosticCommandMBean in any way. The new API
will interface with the existing hotspot native support for dcmds to
allow dcmds to be implemented by and registered from java.
In any case, I think having an API that allows you to invoke a
diagnostic command from java is very different in scope from an API
that allows you to implement one in java, so I'm not so sure this JMX
precedence serves us much purpose here.
Is there anything in the proposal that cannot be done by JMX? If the app
wants to provide a hook to expose some of its internals to be
monitored/controlled by an external tool, maybe it can just implement a
new MBean?
Granted, it's bit more tedious to connect to JMX than using "jcmd".
However, much of that is for security. If we allow an app to implement
new jcmd handlers using Java code, we have to think about the whole
security model again. Are we reinventing the wheel here?
Thanks
- Ioi
