Hello all
The JDK provides us two ways to format localized messages with
parameters: java.text.MessageFormat (since JDK 1.1) and
java.util.Formatter (since JDK 5). The former uses its own syntax like
below:
/Argument '{0}' shall not be negative. The given value was {1}.//
/
The more recent java.util.Formatter class uses a syntax similar to C/C++:
/Argument '%s' shall not be negative. The given value was %f.//
/
The SIS resource bundles currently uses MessageFormat for historical
reasons (created before Formatter was available). However I wonder if we
should revisit that choice. Both MessageFormat and Formatter provide a
wide range of formatting options. Pros and cons that I can see about
Formatter:
Pros:
*
I presume that the Formatter syntax may be more familiar to a wider
range of developers: C/C++ developers, and also the Java ones who
use System.out.printf(...) or String.format(...).
*
Formatter may have slightly more formatting options than
MessageFormat (while I think that MessageFormat flexibility is
sufficient for most cases).
*
We can "plugin" our own formatting rules for SIS classes (e.g. an
Angle class) by implementing the java.util.Formattable interface.
I'm not aware of such plugin mechanism for MessageFormat. We
currently workaround by providing special cases in our
ResourceBundle implementation.
Cons:
*
For those who are not familiar with the C/C++ syntax, the
MessageFormat syntax may be more readable since it is more explicit.
*
MessageFormat has a "choice" type, which seems to have no equivalent
in Formatter. This type is useful for handling plural forms (among
other uses).
*
Formatter forces us to declare the argument type (e.g. "%s" or
"%f"), while MessageFormat infers it from the object type. For
example if the argument could be a string or a number, then
Formatter forces us to use the "%s" type (passing a string to "%f"
causes an exception). However a number formatted with "%s" is
formatted using Number.toString(), which produce an unlocalized
value. By contrast, MessageFormat produce a localized value
dynamically for all recognized types.
Because of the two last "cons", I'm tempted to stick with
MessageFormat. However if something in my analysis is wrong, please let
me known...
Martin