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

[Weijun Wang]

On Fri, 22 Mar 2024 12:18:49 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> It's still necessary I'm afraid. During an early classloader operation, the Security class can be triggered which causes security properties to be read. If debugging is enabled, this triggers loading of CLDR service. Quite a long stack trace but I'll paste it here for history.
>> 
>> I agree on your other comments - I'll try a clean up and will come back to you then.
>> 
>> 
>>  stderr: [Error: A JNI error has occurred, please check your installation and try again
>> Exception in thread "main" java.util.ServiceConfigurationError: Locale provider adapter "CLDR"cannot be instantiated.
>>         at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:193)
>>         at java.base/sun.util.locale.provider.LocaleServiceProviderPool.findProviders(LocaleServiceProviderPool.java:311)
>>         at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl(LocaleServiceProviderPool.java:283)
>>         at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObject(LocaleServiceProviderPool.java:245)
>>         at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNamesImpl(TimeZoneNameUtility.java:197)
>>         at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNames(TimeZoneNameUtility.java:120)
>>         at java.base/java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.getDisplayName(DateTimeFormatterBuilder.java:4484)
>>         at java.base/java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.format(DateTimeFormatterBuilder.java:4535)
>>         at java.base/java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format(DateTimeFormatterBuilder.java:2537)
>>         at java.base/java.time.format.DateTimeFormatter.formatTo(DateTimeFormatter.java:1905)
>>         at java.base/java.time.format.DateTimeFormatter.format(DateTimeFormatter.java:1879)
>>         at java.base/sun.security.util.Debug.extraInfo(Debug.java:345)
>>         at java.base/sun.security.util.Debug.println(Debug.java:299)
>>         at java.base/java.security.Security.loadProps(Security.java:161)
>>         at java.base/java.security.Security.initialize(Security.java:103)
>>         at java.base/java.security.Security.lambda$static$0(Security.java:84)
>>         at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
>>         at java.base/java.security.Security.<clinit>(Security.java:83)
>>         at java.base/sun.security.util.Secu...
>
> 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?

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

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