The attached test case, extracted from the CDC 1.1 TCK
(javasoft.sqe.tests.api.java.text.MessageFormat.SetGetLocaleTests#MessageFormat2252),
illustrates incorrect behavior of MessageFormat.setLocale(). It
fetches all of the available locales on the system; for each one, it
sets the locale of a MessageFormat object which is set up to format a
date, and then compares the result of formatting a Date with that
MessageFormat with the result of formatting the same Date with a
DateFormat instance for that locale. It expects the two formatting
results to be equal.

The test is correct as written. The specification of
MessageFormat.setLocale() states that it affects subsequent calls to
applyPattern() as well as to toPattern(), format() and
formatToCharacterIterator(). The call to setLocale() is clearly not
affecting subsequent calls to format().

There are two ancient Java SE bugs in this area:

4058857 MessageFormat.setLocale doesn't change number or date formats
4281978 MessageFormat's setLocale method does not work

4058857 was fixed in 1.1.6 in 1997 and theoretically corrects this
issue. However, there is a format cache internally to the
MessageFormat object which defeats this fix. 4281978 was filed in 1999
on exactly the same topic, but was closed at the time as "Not a
defect". The evaluation states that the class javadoc for
MessageFormat says that setLocale() can be used in conjunction with
applyPattern() (and possibly setFormat()) to re-initialize a
MessageFormat object. This was true for Java SE releases up to and
including 1.3.1, but in 1.4.x (which the Personal Basis Profile 1.1 is
based on), this sentence was deleted from the class javadoc and was
replaced with the description of setLocale() above, which again states
that it affects subsequent format() calls.

The specification of setLocale() does not match the implementation.
Despite the fix of 4058857 back in 1.1.6, setLocale() has never
affected subsequent calls to, for example, format(). The evaluation of
4281978 clearly shows that the intent was not to fix the
implementation of MessageFormat, but instead to rely on wording of the
specification to force users to call applyFormat() again.

Under the circumstances the MessageFormat.setLocale() javadoc should
probably be modified to not state that it affects subsequent calls to
applyPattern() and toPattern(), rather than changing the MessageFormat
implementation to match the specification, which should probably have
been done back in the 1.1.x or 1.2 timeframe. It is unclear at this
point whether toPattern() works correctly after a call to setLocale().