Summary

Make apparent that MessageFormat.toPattern() does not guarantee the order of equivalence checking for FormatStyles.

Problem

MessageFormat provides pre-defined styles for subformats. For example, a pattern such as "date,long". The issue is that multiple styles could be equivalent, for example, the JDK 23 CLDR Chinese date format has equivalent long and medium styles. Users should not assume that the style they used when creating/setting the MessageFormat will be equivalent to the one produced by toPattern, as this depends on the order that the implementation performs equivalence checking.

Solution

Make apparent in the normative specification that the method does not guarantee any particular order. The added wording is loose enough to still accommodate a particular implementation, if it does want to guarantee such an order.

Specification

Add the following to MessageFormat.toPattern(),

-     * does not necessarily equal the previously applied pattern.
+     * does not necessarily equal the previously applied pattern. The order of
+     * {@code FormatStyle} matching is not guaranteed. That is, a {@code
+     * FormatStyle} produced may not be equivalent to the corresponding style passed,
+     * in the instance that multiple styles are equivalent.