On Fri, 22 Mar 2024 13:29:06 GMT, Weijun Wang <wei...@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
