Fixing performance regression caused by [JDK-8381379](https://bugs.openjdk.org/browse/JDK-8381379). Instead of having each explicit time zone as an entry in the resource bundle, the explicit DST offsets are encoded in one entry. This avoids repeated lookups for missing offsets and eliminates the need for a separate cache. Also `SimpleDateFormat` now issues a new internal `ZoneInfo` method that won't clone instances on each format call. Here is the benchmark result for the test case in the JBS entry (on my mac):
Before: New York: 303.9 B/op, 191.7 ns/op Vancouver: 240.0 B/op, 216.8 ns/op After: New York: 32.0 B/op, 79.5 ns/op Vancouver: 32.0 B/op, 97.5 ns/op These results suggest that the performance has returned to approximately its pre-JDK- 8381379 level. --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - Added empty dstoffset condition (no need for now though) - Refactored the resource bundle format so that caching is not needed - Avoid ZoneInfo copy on each formatting of `z` in SimpleDateFormat - Reverted LocaleResources.java changes - initial commit Changes: https://git.openjdk.org/jdk/pull/33133/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=33133&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8392996 Stats: 61 lines in 7 files changed: 42 ins; 2 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/33133.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/33133/head:pull/33133 PR: https://git.openjdk.org/jdk/pull/33133
