RFR: 8357828: Add a timestamp to jcmd diagnostic commands

[Laurence Cable]

see inline...

On 9/24/25 2:37 AM, Thomas Stuefe wrote:
> On Thu, 18 Sep 2025 14:57:44 GMT, Ivan Bereziuk <duke at openjdk.org> 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