at some point (soon) we should also define a (common) JSON envelope
(schema) for those jcmds that implement a JSON content variant...
IMO it should potentially include:
- jcmd "name"
- JVM version string
- JVM pid
- timestamp
- host "identity"
- content version #
- ...
all jcmds supporting JSON o/p should wrap their content in this std
envelope ...
the motivation for this is that since emitting JSON is primarily
intended to enable programmatic parsing of such content, having the content
be self describing is highly desirable, particularly in a cloud
environment ...
- Larry
On 10/7/25 1:14 PM, Ivan Bereziuk wrote:
On Wed, 24 Sep 2025 22:24:35 GMT, Larry Cable <[email protected]> wrote:
My proposal would entail
* adding a new standard option to jcmd
* somehow funneling that option to the JVM
* the option should be optional, so that:
* old jcmd still works with new JVMs (and produces legacy jcmd output)
* new jcmd still works with old JVMs (and produces legacy jcmd output)
How complex would this be? There are two approaches to this. You
can either create a new attach listener protocol (we already have
ATTACH_API_V2 vs ATTACH_API_V1, so the precedence is there). Or,
you can expand the jcmd parsing (see |jcmd(AttachOperation* op,
attachStream* out)| in attachListener.cpp).
ATTACH_API_V2 supports "options".
Client (jcmd) detects options supported by the target VM ("getversion
options" command) and can set option values in attach command request.
Currently the only supported option is "streaming" (it allows turn off
streaming output).
The option is needed only for tests and needs to work for all attach
tools (jcmd, jstack, etc.), so it can be set by specifying java
property launching attach tool (like |jcmd
-J-Djdk.attach.allowStreamingOutput=false PID command|)
Agreed. I will be working on the proposal. Thank you.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3360367314
