JDK-4152725 : Locales specified via command line not recognized
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.1.6,1.3.0,1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux,windows_nt
  • CPU: generic,x86
  • Submitted: 1998-06-26
  • Updated: 2001-06-19
  • Resolved: 2001-06-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
1.4.0 beta2Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  

Name: clC74495			Date: 06/26/98

This bug was thrown aside (4097828)
as you rushed to release jdk1.1.6
as not being reproduceable but this
bug exists in jdk1.1.6 as well as
jdk1.1.5.  i don't think this is a 

I am currently using Japanese WinNT4.0
platform and creating a bilingual program
(Japanese/English).  I would like to be able
to specify the Locale to be used as the 
default from the command line but setting
the user.language and user.region system
properties via the command line do not affect
the default Locale.

run the program below (in a Japanase environment) as

java  -Duser.language=en -Duser.region=US LocaleTest

the program recognizes the specified Locale as en_US
but still uses the Locale ja_JP as its default Locale!

this causes problems when using internationalization
in that the resources loaded are the Japanese
resources, but the system attempts to display
them in English (resulting in undefined character
"boxes" all over all of the menus and window
titles on screen)

--- source code begin ---

import java.util.Locale;

public class LocaleTest

    static public void main(String[] args)
	Locale defLoc = Locale.getDefault();
	String dLang = defLoc.getLanguage();
	String dRegion = defLoc.getCountry();
	System.out.println("Default Locale = "+dLang+"_"+dRegion);

	String language = System.getProperty("user.language", "en");
	String region = System.getProperty("user.region", "US");
	System.out.println("Specified Locale = "+language+"_"+region);

--- source code end ---
(Review ID: 30753)

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta2 FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2

WORK AROUND Name: clC74495 Date: 06/26/98 after getting the system properties for the locale, create the locale and install it as the default: String language = System.getProperty("user.language", "en"); String region = System.getProperty("user.region", "US"); Locale curLoc = new Locale(language, region); Locale.setDefault(curLoc); ======================================================================

EVALUATION Setting the default locale from the command line works in some environments, but not in others. It should work consistently everywhere. Note that some parts of the J2RE (e.g., the input method framework) depend on knowing the actual host OS locale. We therefore need a separate property for the host OS locale. norbert.lindenberg@Eng 2001-05-04 The problem seems to be that in some circumstances the default locale is initialized too early, before the command line options have been read. One reason is character conversion: In order to interpret strings (including command line options) that may be written in the native encoding, character conversion is needed. For some encodings (ISO 8859-1, US-ASCII, Cp1252), this is done in native code. For other encodings, the character conversion frameworks are initialized. Since they need to be able to look up encodings by name without respect to case, they use case conversion with the US Locale. For that, they construct a Locale, triggering initialization of the Locale class, which defines the default Locale. Fix: Move the initialization of the default locale out of the static initializer back into Locale.getDefault. To avoid synchronization problems, call Locale.getDefault after the system properties have been set up. A related problem is that we only define user.language and user.region, while the variant is encoded into the region. There should be separate user.language, user.region, and user.variant. norbert.lindenberg@Eng 2001-05-15 Further investigation shows that a separate OS locale may not work that well in practice. It turns out that a number of regression tests rely on the ability to set the locale used for the font.properties file selection from the command line, and I had thought that this selection is one of the main cases where the OS locale should be used. norbert.lindenberg@Eng 2001-05-16 After more discussions, here's the complete fix: - the native runtime initializes user.language, user.country, and user.variant. - these system properties can be overridden from the command line. - Locale creates the initial default locale when asked for it the first time, which is safely after the command line has been read. For compatibility with older implementations, it uses user.region if specified, otherwise user.country and user.variant. - SunToolkit provides a startup locale which is the same as the initial default locale, but cannot be changed. This locale is used for input methods, font properties, and similar functionality. norbert.lindenberg@Eng 2001-06-11