On Thu, 14 Mar 2024 17:13:15 GMT, Sean Coffey <coff...@openjdk.org> wrote:
>> src/java.base/share/classes/sun/security/util/Debug.java line 181: >> >>> 179: d.printDateTime = getConfigInfo(option, "+timestamp"); >>> 180: if (d.printDateTime && !dateTimeFormatInitialized) { >>> 181: // trigger loading of Locale service impl now to avoid >> >> You may want to try the test case added in JDK-8280890 with debugging >> enabled to make sure you don't get a similar recursion issue. > > interesting - I did add `-Djava,security.debug=all ` to the internals of that > test and see issues. > > However - they're issues that exist even without my patch. I need to take a > closer look. `sun.util.locale.provider.LocaleServiceProviderPool` doesn't > like to be invoked too early. That's a concern - maybe it should be able to > handle such scenarios and return a simple/default Locale provider. > > > Caused by: java.lang.IllegalStateException: getSystemClassLoader cannot be > called during the system class loader instantiation > at > java.lang.ClassLoader.getSystemClassLoader([java.base@23-ea](mailto:java.base@23-ea)/ClassLoader.java:1952) > at > java.lang.ClassLoader.getSystemResources([java.base@23-ea](mailto:java.base@23-ea)/ClassLoader.java:1723) > at > java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass([java.base@23-ea](mailto:java.base@23-ea)/ServiceLoader.java:1189) > at > java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService([java.base@23-ea](mailto:java.base@23-ea)/ServiceLoader.java:1224) > at > java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext([java.base@23-ea](mailto:java.base@23-ea)/ServiceLoader.java:1269) > at > java.util.ServiceLoader$2.hasNext([java.base@23-ea](mailto:java.base@23-ea)/ServiceLoader.java:1305) > at > java.util.ServiceLoader$3.hasNext([java.base@23-ea](mailto:java.base@23-ea)/ServiceLoader.java:1387) > at > sun.util.cldr.CLDRLocaleProviderAdapter.lambda$new$0([java.base@23-ea](mailto:java.base@23-ea)/CLDRLocaleProviderAdapter.java:84) > at > java.security.AccessController.doPrivileged([java.base@23-ea](mailto:java.base@23-ea)/AccessController.java:571) > at > sun.util.cldr.CLDRLocaleProviderAdapter.<init>([java.base@23-ea](mailto:java.base@23-ea)/CLDRLocaleProviderAdapter.java:83) > at > jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance([java.base@23-ea](mailto:java.base@23-ea)/DirectConstructorHandleAccessor.java:62) > at > java.lang.reflect.Constructor.newInstanceWithCaller([java.base@23-ea](mailto:java.base@23-ea)/Constructor.java:502) > at > java.lang.reflect.Constructor.newInstance([java.base@23-ea](mailto:java.base@23-ea)/Constructor.java:486) > at > sun.util.locale.provider.LocaleProviderAdapter.forType([java.base@23-ea](mailto:java.base@23-ea)/LocaleProviderAdapter.java:182) > at > sun.util.locale.provider.LocaleServiceProviderPool.findProviders([java.base@23-ea](mailto:java.base@23-ea)/LocaleServiceProviderPool.java:311) > at > sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl([java.base@23-ea](mailto:java.bas... Interesting. It seems any attempt to calls like `Date.toString()` early on that triggers a `TimeZone` lookup is going to potentially cause this. A possible workaround is to change `CertificateValidity.toString()` to emit dates as `Date.toInstant().toString()` which is similar to what I did in the fix for JDK-8280890. But this is a separate issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18084#discussion_r1526645217