On Fri, 22 Mar 2024 12:18:49 GMT, Sean Coffey <coff...@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
