A DESCRIPTION OF THE PROBLEM :
Under rare circumstances JVM throws  java.util.MissingResourceException: Can't find bundle for base name sun.util.resources.cldr.TimeZoneNames, locale en_US and the same message appears in the date line of JInfo System properties. 
20240405.162119 Caused by: java.util.MissingResourceException: Can't find bundle for base name sun.util.resources.cldr.TimeZoneNames, locale en_US
20240405.162119 at java.base/sun.util.resources.Bundles.throwMissingResourceException(Bundles.java:302)
20240405.162119 at java.base/sun.util.resources.Bundles.loadBundleOf(Bundles.java:147)
20240405.162119 at java.base/sun.util.resources.Bundles.of(Bundles.java:106)
20240405.162119 at java.base/sun.util.resources.LocaleData$1.run(LocaleData.java:186)
20240405.162119 at java.base/sun.util.resources.LocaleData$1.run(LocaleData.java:183)
20240405.162119 at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
20240405.162119 at java.base/sun.util.resources.LocaleData.getBundle(LocaleData.java:183)
20240405.162119 at java.base/sun.util.resources.LocaleData.getTimeZoneNames(LocaleData.java:114)
20240405.162119 at java.base/sun.util.locale.provider.LocaleResources.getTimeZoneNames(LocaleResources.java:280)
20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameProviderImpl.getDisplayNameArray(TimeZoneNameProviderImpl.java:127)
20240405.162119 at java.base/sun.util.cldr.CLDRTimeZoneNameProviderImpl.getDisplayNameArray(CLDRTimeZoneNameProviderImpl.java:75)
20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameProviderImpl.getDisplayName(TimeZoneNameProviderImpl.java:99)
20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getName(TimeZoneNameUtility.java:271)
20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getObject(TimeZoneNameUtility.java:229)
20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getObject(TimeZoneNameUtility.java:215)
20240405.162119 at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl(LocaleServiceProviderPool.java:275)
20240405.162119 at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObject(LocaleServiceProviderPool.java:236)
20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNamesImpl(TimeZoneNameUtility.java:197)
20240405.162119 at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayName(TimeZoneNameUtility.java:150)
20240405.162119 at java.base/java.util.TimeZone.getDisplayName(TimeZone.java:402)
20240405.162119 at java.base/java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1306)
20240405.162119 at java.base/java.text.SimpleDateFormat.format(SimpleDateFormat.java:1001)
20240405.162119 at java.base/java.text.SimpleDateFormat.format(SimpleDateFormat.java:971)
20240405.162119 at java.base/java.text.DateFormat.format(DateFormat.java:378)
...
I don't have a reliable reproducer, but this looks like a race condition between JVM startup and external invocation of JInfo command. Heapdump had an  unreachable Bundles$CacheKey that had cause NPE with the following backtrace:Type|Name|Value
---------------------------------------------------------------------------------------------
ref |[0] |class java.util.Objects @ 0x7bf808858
ref |[1] |class java.lang.Class @ 0x7bf800d88
ref |[2] |class sun.util.resources.Bundles @ 0x7bf070120
ref |[3] |class sun.util.resources.Bundles @ 0x7bf070120
ref |[4] |class sun.util.resources.Bundles @ 0x7bf070120
ref |[5] |class sun.util.resources.Bundles @ 0x7bf070120
ref |[6] |class sun.util.resources.Bundles @ 0x7bf070120
ref |[7] |class sun.util.resources.LocaleData$1 @ 0x7bf06fd98
ref |[8] |class sun.util.resources.LocaleData$1 @ 0x7bf06fd98
ref |[9] |class java.security.AccessController @ 0x7bf801578
ref |[10]|class sun.util.resources.LocaleData @ 0x7bf06f9a0
ref |[11]|class sun.util.resources.LocaleData @ 0x7bf06f9a0
ref |[12]|class sun.util.locale.provider.LocaleResources @ 0x7bf06f470
ref |[13]|class sun.util.locale.provider.TimeZoneNameProviderImpl @ 0x7bf068040
ref |[14]|class sun.util.cldr.CLDRTimeZoneNameProviderImpl @ 0x7bf0680c8
ref |[15]|class sun.util.locale.provider.TimeZoneNameProviderImpl @ 0x7bf068040
ref |[16]|class sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter @ 0x7bf040f08
ref |[17]|class sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter @ 0x7bf040f08
ref |[18]|class sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter @ 0x7bf040f08
ref |[19]|class sun.util.locale.provider.LocaleServiceProviderPool @ 0x7bf0407e0
ref |[20]|class sun.util.locale.provider.LocaleServiceProviderPool @ 0x7bf0407e0
ref |[21]|class sun.util.locale.provider.TimeZoneNameUtility @ 0x7bf0405b8
ref |[22]|class sun.util.locale.provider.TimeZoneNameUtility @ 0x7bf0405b8
ref |[23]|class java.util.TimeZone @ 0x7bf00de70
ref |[24]|class java.util.Date @ 0x7bf00ce90
ref |[25]|class java.util.Properties @ 0x7bf8023b8
ref |[26]|class java.util.Properties @ 0x7bf8023b8
ref |[27]|class jdk.internal.vm.VMSupport @ 0x7bf000800
ref |[28]|class jdk.internal.vm.VMSupport @ 0x7bf000800
---------------------------------------------------------------------------------------------
Jinfo tries to print the current date for system properties and gets NPE from VMSupport->Properties-> new Date() -> ... ->Bundles->Class->Objects.  I didn't deconstruct NPE backtrace, but is it possible that the Bundles.module at this stage is still null and it results in caching Bundles$CacheKey with NPE cause?

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This looks very timing related, I couldn't reproduce it with a simple main, but could trigger it by running Tomcat restarts and Jinfo on process in the loop. It happened mostly on VMs with just 4 cores and 24g xmx/xms with AlwaysPreTouch. We've encountered it just a few times on different hardware configurations. In general it happens on ~ 0.01% of restarts, but with this hardware setup it was >1% of restarts.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No exceptions thrown in application and successful Jinfo invocation
ACTUAL -
Jinfo doesn't print System properties and application throws java.util.MissingResourceException: Can't find bundle for base name sun.util.resources.cldr.TimeZoneNames, locale en_US

CUSTOMER SUBMITTED WORKAROUND :
Couldn't reproduce an error after postponing Jinfo invocation.


FREQUENCY : rarely