RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter

[Justin Lu]

On Wed, 31 Jan 2024 22:24:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations.
> 
> The `FormatTypes`:  dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added.
> The `FormatStyles`: compact_short, compact_long, or, and unit are added.
> 
> For example, previously,
> 
> 
> Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)};
> MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args);
> 
> 
> would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date`
> 
> Now, a user can call
> 
> 
> MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args);
> 
> 
> which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023"

> Slightly tangential question (since you're talking about adding new subformats)...
> 
> Has it ever been considered to add `MessageFormat` itself as a subformat option?
> 
> It's not as crazy an idea as it sounds :) Here's an example:
> 
> ```java
> MessageFormat f = new MessageFormat(
>   "Result: {0,choice,0#no letters|1#one letter: {1,message,'{0}'}|2#two letters: {1,message,'{0} and {1}'}}");
> f.format(new Object[] { 2, new Object[] { "A", "B" } });    // "Result: two letters: A and B"
> ```

Definitely an interesting idea, although I think the pattern syntax is generally reserved for common use cases, I'm not sure if this would be that common. Something to think about/consider though, although it would be beyond the scope of this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/17663#issuecomment-1924779134