RFR: 8051959: Add decorator options for java.security.debug output [v2]

[Sean Mullan]

On Thu, 14 Mar 2024 17:13:15 GMT, Sean Coffey <coffeys at 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 at 23-ea](mailto:java.base at 23-ea)/ClassLoader.java:1952)
> at java.lang.ClassLoader.getSystemResources([java.base at 23-ea](mailto:java.base at 23-ea)/ClassLoader.java:1723)
> at java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1189)
> at java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1224)
> at java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1269)
> at java.util.ServiceLoader$2.hasNext([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1305)
> at java.util.ServiceLoader$3.hasNext([java.base at 23-ea](mailto:java.base at 23-ea)/ServiceLoader.java:1387)
> at sun.util.cldr.CLDRLocaleProviderAdapter.lambda$new$0([java.base at 23-ea](mailto:java.base at 23-ea)/CLDRLocaleProviderAdapter.java:84)
> at java.security.AccessController.doPrivileged([java.base at 23-ea](mailto:java.base at 23-ea)/AccessController.java:571)
> at sun.util.cldr.CLDRLocaleProviderAdapter.<init>([java.base at 23-ea](mailto:java.base at 23-ea)/CLDRLocaleProviderAdapter.java:83)
> at jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance([java.base at 23-ea](mailto:java.base at 23-ea)/DirectConstructorHandleAccessor.java:62)
> at java.lang.reflect.Constructor.newInstanceWithCaller([java.base at 23-ea](mailto:java.base at 23-ea)/Constructor.java:502)
> at java.lang.reflect.Constructor.newInstance([java.base at 23-ea](mailto:java.base at 23-ea)/Constructor.java:486)
> at sun.util.locale.provider.LocaleProviderAdapter.forType([java.base at 23-ea](mailto:java.base at 23-ea)/LocaleProviderAdapter.java:182)
> at sun.util.locale.provider.LocaleServiceProviderPool.findProviders([java.base at 23-ea](mailto:java.base at 23-ea)/LocaleServiceProviderPool.java:311)
> at sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl([java.base at 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