On Mon, 24 Apr 2023 21:02:01 GMT, Justin Lu <j...@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`. Great to see this intermittent issue solved, Justin! A minor suggestion: test/jdk/java/text/Format/DateFormat/DateFormatRegression.java line 360: > 358: TimeZone def = TimeZone.getDefault(); > 359: try { > 360: TimeZone z = new SimpleTimeZone((int)(8.25 * 3600000), > "GMT-08:15"); If we want a custom zone, simply `TimeZone.getTimeZone("GMT-08:15")` will do. ------------- PR Review: https://git.openjdk.org/jdk/pull/13630#pullrequestreview-1398894333 PR Review Comment: https://git.openjdk.org/jdk/pull/13630#discussion_r1175839321
