On Fri, 22 Mar 2024 09:36:35 GMT, Sean Coffey <[email protected]> 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
