|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 4
Java provides us with several tools to make internationalizing message text much simpler. The java.text.MessageFormat class allows us to parameterize textual error messages. MessageFormat resembles the printf function in C, but is even more flexible, as it allows for parameter reordering in the format string. The following version
of Listing 1 is slightly better because it doesn't hide the error message text in the middle of the code:
Listing 2. Build error messages with MessageFormat
public static final String MSG_FILE_NOT_FOUND = "Cannot find file {1}";
...
public static String formatMessage(String messageString, Object arg0) {
MessageFormat mf = new MessageFormat(messageString);
Object[] args = new Object[1];
args[0] = arg0;
return mf.format(args);
}
...
if (!file.exists()) {
throw new ResourceException(formatMessage(MSG_FILE_NOT_FOUND,
file.getName()));
}
This version is better than the first in several ways: The error message is separated (somewhat) from the code, so it is much easier to find when localizing the class. Separating the error message from the code reduces the work required for localization and reduces the chance that an error message will be missed. It also encourages developers to reuse the same message if multiple methods throw the same error so the program will be more likely to have a consistent set of error messages.
However, this technique, while a big improvement, still puts the error message text inside the source code, which causes several problems. Localizers must have access to the source code, which might be a political problem in some organizations. Also, multiple codeline branches must be managed and merged to produce localized versions when the classes are updated. A much better approach would take the error messages completely out of the Java classes that throw them and migrate them into some sort of resource database, sometimes called a message catalog.
Message catalogs are nothing new -- the original MacOS (1984) provided a sophisticated resource manager for storing user interface
items separately from the program code. Even before that, the VMS (Virtual Memory System, circa 1978) operating system had
a mechanism for storing message strings separately from the program for simple localization. While it's easy to build your
own message catalog facility, the Java class libraries already provide a useful mechanism for managing localized resources,
the ResourceBundle class. A ResourceBundle stores a set of key-value pairs; the key names are static and specific to the program, but the values might change from locale
to locale. The Java class libraries provide several helper classes for simplifying the resource bundle process, ListResourceBundle and PropertyResourceBundle.
You construct a resource bundle by creating one or more classes that implement ResourceBundle and use a special naming convention to associate the concrete implementation class with a locale. For example, suppose you
want to create a resource bundle called com.foo.FooResources and provide implementations for English, French, and German. To do that, you would create a default implementation class
called com.foo.FooResources and then additional implementations for other locales named com.foo.FooResources_en (which might be the same as the default), com.foo.FooResources_fr, and com.foo.FooResources_de. You could create additional localized versions later. The ResourceBundle class will use the current locale to find the most appropriate version of the resource bundle; if the class can't find a
localized version, it will use the default.