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 @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. Thinking this a bit further. We may have the same discussion in the future whenever we do fundamental changes to jcmd output. 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. 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. 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? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3327445191
