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

Reply via email to