On Tue, 15 Sep 2026 02:39:52 GMT, moseoh <[email protected]> wrote:
> `CLDRTimeZoneNameProviderImpl.getDisplayNameArray()` modifies the array
> cached by `LocaleResources` when filling in missing time zone names.
> As a result, names derived for a parent locale can be reused by a later
> lookup for a child locale, making the result depend on lookup order.
>
> This change copies the array before updating the zone ID and deriving
> fallback names, leaving the cached array unchanged.
>
> `TimeZoneNameOrderTest` compares a direct lookup with a lookup made after
> querying the parent locale. The two runs use separate JVMs so that they
> do not share cached state.
>
> `TimeZoneNameConcurrencyTest` compares concurrent first lookups with
> sequential lookups in a fresh JVM. It is included to cover the race seen
> in 11u/17u/21u; it passes on mainline both before and after the fix.
>
> Tested with jtreg sun/util, java/util/TimeZone and java/util/Locale on
> linux-x64.
>
> ---------
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK
> Interim AI Policy](https://openjdk.org/legal/ai).
The fix looks good.
test/jdk/sun/util/locale/provider/TimeZoneNameConcurrencyTest.java line 85:
> 83: try {
> 84: barrier.await();
> 85: tz.getDisplayName(false, TimeZone.SHORT, l);
I'd check the name returned by this `tz.getDisplayName()` call as well. The
current code may miss cases where this call returns an inconsistent name.
-------------
PR Review: https://git.openjdk.org/jdk/pull/32867#pullrequestreview-5295001392
PR Review Comment: https://git.openjdk.org/jdk/pull/32867#discussion_r4085853537
