RFR: 8051959: Add thread and timestamp options to java.security.debug system property [v3]

[Weijun Wang]

On Fri, 22 Mar 2024 13:29:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Turns out that it's the `java.time.format.DateTimeFormatterBuilder.ZoneTextPrinterParser#format` call that triggers the early initialization of the CLDR service (via a `getDisplayName` call)
>> 
>> We can avoid this call if we print time data without timezone ID - i.e. 
>> using a pattern of "yyyy-MM-dd kk:mm:ss.SSS" rather than "yyyy-MM-dd kk:mm:ss.SSS z"
>> 
>> example of change: (no UTC printed)
>> (with display name) :
>> ` properties[2024-03-22 09:55:48.985 UTC]: Initial security property: keystore.type.compat=true`
>> 
>> (without):
>>  `properties[2024-03-22 09:55:48.985]: Initial security property: keystore.type.compat=true`
>> 
>> I think we can live without the display name detail. Most logs relate to local timezone systems. It shortens the print also.
>
> Yes, using local timezone is OK. Your new test adds a `-Duser.timezone=UTC` and I doubt anyone is likely to change that.
> 
> Back to my comment, I don't understand how this could fix the recursion. This check is also done very early and why doesn't that `FormatHolder.DATE_TIME_FORMATTER.format(Instant.now())` trigger a similar error?

In fact, I just tried `java -Djava.security.debug=all+timestamp sun.security.util.Debug` and there is an error no matter the if block is there or not.

I'm running with an exploded build. Hopefully that makes no difference.

And, both case are fine if the `Z` is removed from `PATTERN`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1535578787