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