On Fri, 22 Mar 2024 09:36:35 GMT, Sean Coffey <coff...@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

Reply via email to