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

[Sean Coffey]

On Fri, 22 Mar 2024 09:36:35 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/Debug.java line 191:
>> 
>>> 189:         if (printDateTime && !dateTimeFormatInitialized) {
>>> 190:             // trigger loading of Locale service impl now to avoid
>>> 191:             // possible bootstrap recursive class load issue
>> 
>> Does this need to be manually loaded? I thought the `FormatHolder` field will be automatically loaded when it's first accessed and only once.
>
> 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.SecurityProperties.getOverridableProperty(SecurityProper...

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.

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

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