see inline...
On 9/24/25 2:37 AM, Thomas Stuefe wrote:
On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <[email protected]> wrote:
`jcmd` provides great diagnostics but many commands lack a timestamp in their
output.
Adding a timestamp to the output of some would add value for those debugging
JVM data.
Some diagnostic commands already provide timestamps. For example `Thread.print` already
prints one of "yyyy-MM-dd HH:mm:ss" format.
Adding timestamps to all diagnostic `jcmd` commands with a non-throw-away
STDOUT.
The exceptions are:
* `VM.uptime` - command run with `-date` argument will also print a timestamp;
* `VM.system_properties` - already lists timestamp
* `Thread.dump_to_file` - the content dumped to file already has a timestamp;
* `VM.version`
@larry-cable
anyone who is parsing the output of jcmd's programmatically ... since
this change can potentially break that code
yeah, true
thanks!
@Domest0s
Hmm, rather than breaking compatibility and requiring a CSR, I now also opt for
an option. We are usually not so strict with changing individual commands, but
I agree with Larry that changing the format of all commands may be a problem.
cheers!
Thinking this a bit further. We may have the same discussion in the future
whenever we do fundamental changes to jcmd output.
agreed!
As an arbitrary example, let's say someone wants to report the jcmd runtime back at the
end of every command (I recently needed that, but abandoned the PR). E.g. a trailing
"321ms". Or some other statistics or process specs. Do we want a new diagnostic
switch every time? That could get confusing quickly, and these switches need testing.
agreed
How about a single "enable jcmd legacy output format" setting. By default on.
Behind this setting we guard all future changes that severely change the output of
commands. Anyone wanting a stable output would define that setting.
agreed
And how about making this switch a standard *jcmd* option, not a JVM setting?
Typically, this decision is made by the analyst running jcmd. That is the
person wanting to post-process the output. A JVM switch means the analyst has
to restart the JVM with new command-line parameters. That is uncomfortable, and
the analyst may even be able to do that (often can't restart client production
servers; maybe not even change VM parameters).
Opinions?
makes sense, I have a (much) larger dream for jcmd etc that I want to
work on:
1) add Unix Domain Socket support to the (sun) enbedded httpserver
2) expose a UDS endpoint for Jcmds'
3) add http+json as a transport for commands and responses
4) add mechanism for DCmd to render in json
with json as a payload format such additions would be much simpler...(in
theory at least)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3327445191
