On Tue, 28 Apr 2026 23:37:37 GMT, Naoto Sato <[email protected]> wrote:
> Enabling customization of localized format patterns for the `java.time` > date/time formatters through the locale-sensitive SPI. While existing SPIs > allow customization of textual elements, such as month-of-year names, > formatting patterns (e.g., "dd/MM/yyyy") cannot currently be customized for a > given locale. > > This enhancement is needed to support customers migrating from the > now-removed COMPAT locale resources to CLDR-based ones. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). src/java.base/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java line 176: > 174: public String getDateTimeFormatterPattern(String > requestedTemplate, String calType, Locale locale) { > 175: // Not supported. Return the requestedTemplate as is. > 176: return requestedTemplate; I think this introduces a behavioral change and is not ideal behavior. Before, the default implementation threw `DateTimeException` for these methods. However, in the new HOST code we are returning the pattern as is. Thus, users who invoke methods that delegate to this code will silently succeed with non-supported patterns. src/java.base/share/classes/java/time/format/DateTimeFormatterPatternProvider.java line 47: > 45: */ > 46: > 47: public abstract class DateTimeFormatterPatternProvider extends > LocaleServiceProvider { I presume it is an intentional decision to not add this class to the `spiClasses` array within `LocaleServiceProviderPool` because this is a more specific provider within `DateTimeFormatter`, the provider does not map 1-1 with a corresponding public class, and `DateTimeFormatter` itself does not expose a `getAvailableLocales` method? (Even if an SPI that included a locale for this provider is now omitted from `Locale.getAvailableLocales()`. src/java.base/share/classes/java/time/format/DateTimeFormatterPatternProvider.java line 76: > 74: * @see Chronology#getCalendarType() > 75: */ > 76: public abstract String getDateTimeFormatterPattern(FormatStyle > dateStyle, While not relevant to the JDK implementations (I believe), should we specify what happens when the given styles are not supported, such that SPI implementations have contract guidance to if they fall under that case? (Similar to how the pattern template method specifies the behavior when the pattern is non supported.) src/java.base/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java line 1: > 1: /* Copyright year needs an update. src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java line 110: > 108: return c.cast(getDateTimeFormatterPatternProvider()); > 109: } else { > 110: throw new InternalError("should not come down here"); Unrelated to this PR, but I feel that this String should be a comment, and the actual message something more relevant, in the case that it would ever actually go down there... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30979#discussion_r3163342845 PR Review Comment: https://git.openjdk.org/jdk/pull/30979#discussion_r3163451200 PR Review Comment: https://git.openjdk.org/jdk/pull/30979#discussion_r3163501954 PR Review Comment: https://git.openjdk.org/jdk/pull/30979#discussion_r3163456625 PR Review Comment: https://git.openjdk.org/jdk/pull/30979#discussion_r3163518562
