Java Tutorial

Fixing Locale-Sensitive Methods

In this section, you will fix another kind of issue detected by the scanner: Locale-Sensitive Methods (also referred to as Unsafe Methods in previous version of Globalyzer).

Locale-Sensitive Methods are methods or functions that return locale-specific results. For example, methods that format dates and currency information must be written to take the user's locale into consideration. Within C and C++, functions and methods often iterate through an array of characters, assuming a single byte per character or assuming ASCII values. In international environments, the Unicode character encoding is often required and Unicode characters, except in the case of UTF-8, are always more than a single byte. To properly fix a locale-sensitive method, you typically need to do one of the following:

  • replace a locale-sensitive method with another method that is safe for the targeted locales and character encodings
  • modify the method call to include locale information, such as a Locale object in Java

Clearly, the procedure you follow in your own projects will depend on your particular system architecture, including the language you are using, how locale information is stored and retrieved, and so on.

Note: an online video guide is available for this section of the tutorial. To see this video, as well as other Globalyzer video tutorials, click here. The video guide relevant to this tutorial is titled Part Five: Externalizing String and Pseudo-Localization.

  1. Select Locale-Sensitive Methods in the Results dropdown within the Scan Results window.
  2. There are six issues. Four formatting issues, and two issue for setLocale: in this tutorial, you are going to ignore the setLocale methods. You should follow the same procedure as for ignoring a String, which you did in a previous section. (Hint: right click the issue and select Ignore this Line for a permanent result)

  3. Before fixing the date/time formatting issues, let's look at the All Predicted Scan Summary that was generated when you scanned the code. It can be found in the lower left of the window.

  4. In the Summary view, scroll down to the Locale-Sensitive Methods section. You will find links to a date and a time method, both under the Date/Time category. Click each link to view more detailed information about the issues.

    Tip: Use the All Predicted Scan Summary view to find detailed information on locale-sensitive methods. Just click on a detected method link and Globalyzer will display the associated help page. This information can be useful in assisting you to re-code or replace the method call.

  5. In the Scan Results table, double-click the row containing the locale-sensitive method with DateFormat.getTimeInstance(...). This opens the associated source file and highlights the method call in the Editor view.

    The reason this line represents a potential error is that the getTimeInstance method actually has several overloaded signatures. In this case, the method takes no parameters and uses the system's default locale to format the time.

  6. In the Editor view, revise the getDateInstance method as follows:

    datePanel_.add(new JLabel(DateFormat.getDateInstance(DateFormat.FULL, I18nUtils.getLocale()).format(today_)), constraints); // $NON-NLS-L$

    In this case, the locale is retrieved with the I18nUtils.getLocale method, which is responsible for getting whatever locale was maintained for the application (here French from France). Please note the DateFormat.FULL parameter, which simply formats the date string as follows (for a US/English locale): Monday, May 17, 2012

  7. The tag added at the end of the line, // $NON-NLS-L$ , lets Globalyzer know to ignore this line for the next scan. The software engineer who corrected the line now considers it is not an i18n issue any longer. There is another method to remove the locale-sensitive method from the Scan Results table: change its Prediction to F by right-clicking on the row and selecting Mark Prediction: False. If you are using the Scan View All Predicted Active, issues with F predictions will not be displayed in the Scan Results.

  8. Note that the call to DateFormat.getDateInstance (as well as DateFormat.getTimeInstance) creates a DateFormatter object, based on a locale (default or passed in). This particular call to the format method applies the DateFormat using that initial locale. Hence the format call is not i18n issues in this particular lines of code.

  9. Make similar changes for the second Locale-Sensitive Method error, changing the code to the following:

    datePanel_.add(new JLabel(DateFormat.getTimeInstance(DateFormat.DEFAULT, I18nUtils.getLocale()).format(time_)), constraints); // $NON-NLS-L$

  10. Save the source file by selecting File=>Save or by typing Ctrl-S.

You have now fixed two locale-sensitive methods by locating them using the Scan Results table and directly editing the source files. Previously, you used the Scan Results table to locate embedded strings and fixed them by using Globalyzer's String Externalization feature. The final step is to test your code changes.