[leapingdog]

String.format is much newer - it wasn't introduced until JDK 1.5.

The choice expression is intended to account for different I18N language conventions. Imagine a language where pluralization works differently to none/one/plural. If you don't work on localized applications you can mostly ignore the MessageFormat type.

MessageFormat is often used in conjunction with ResourceBundle and properties files. The string is likely externalized and distributed to translators. That's probably not the case for String.format strings.

In real life you would typically just have "File count: " and concatenate a number. Translators weren't wild about it but they could work with it. Translators are typically not programmers and many would break any complex expression.

All the types in java.text are a bit archaic. They are basically impossible to reuse in a thread-safe manner. MessageFormat delegates a bunch of other Format instances. There's a lot of parsing and state there. Time zone handling is awkward.

I agree about the error-prone nature of this approach. I have written a library[0] that verifies MessageFormat syntax in properties files at compile time and generates typed methods for each property.

[0] https://github.com/autores-uk/autores

[tail_exchange]

I didn't consider the usage of ResourceBundle. It does make a lot more sense now!