<i18n dev> RFR: 8305853: java/text/Format/DateFormat/DateFormatRegression.java fails with "Uncaught exception thrown in test method Test4089106" [v2]

Lance Andersen lancea at openjdk.org
Tue Apr 25 17:00:10 UTC 2023


On Mon, 24 Apr 2023 23:47:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR fixes an intermittent failure (that only occurs on Windows) in _DateFormatRegression.java_.
>> 
>> With the integration of [JDK-8304982](https://bugs.openjdk.org/browse/JDK-8304982), _LocaleProviderAdapter.java_ now emits a compat warning when the class is loaded. This warning calls `ZonedDateTime.now()` during formatting. This call depends on the `TimeZone.ID` of the TimeZone returned from `TimeZone.getDefault()`.
>> 
>> On Windows, the test class which DateFormatRegression extends will run the tests at random, (as opposed to running in the same order every time). When Test4089106() happens to be the first test ran, the static block of LocaleProviderAdapter will be executed with `TimeZone.setDefault()` set to a `SimpleTimeZone` with `id` as _FAKEZONE_. When LocaleProviderAdapter formats the compat warning ... and many calls later calls `ZoneRulesProvider getProvider(String zoneId)` with `zoneId` as _FAKEZONE_ the test fails with _java.time.zone.ZoneRulesException: Unknown time-zone ID: FAKEZONE_.
>> 
>> In order to still test that `SimpleDateFormat.getTimeZone()` defaults to `TimeZone.getDefault()` we can create a `SimpleTimeZone` with a custom id rather than an invalid id. This way ZoneRulesProvider will not fail on the ID, but the `SimpleTimeZone` being tested is still not a "default" `TimeZone`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup / alternate custom tz

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13630#pullrequestreview-1400354287


More information about the i18n-dev mailing list