JDK-6457127 : Indonesian Locale does not comply with ISO 639
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-08-04
  • Updated: 2013-07-03
  • Resolved: 2013-07-03
Related Reports
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.5.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
The indonesian locale gets parsed from both the identifiers "id" and "in". ISO 639 specifies only "id" as correct. When you ask the locale object for its representation, it returns "in", which is not correct.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the following demonstration:

-------------------------------------------------------------
import java.util.Locale;

public class ManualIndonesianLocaleTest {

    public static void main(String[] args) {
        Locale iso639Indonesian = new Locale("id");
        testForSpecificationCompliance(iso639Indonesian);
        System.out.println();
        Locale someOtherIndonesian = new Locale("in");
        testForSpecificationCompliance(someOtherIndonesian);
    }
    
    private static void testForSpecificationCompliance(Locale indonesian) {
        System.out.println("Locale " + indonesian + " stands for Indonesian: " + isLocaleDenotedAsIndonesian(indonesian));
        System.out.println("Language representation (" + indonesian.getLanguage() + ") complies with ISO 639: " + isISO639Representation(indonesian.getLanguage()));
        System.out.println("Locale representation (" + indonesian.toString() + ") complies with ISO 639: " + isISO639Representation(indonesian.toString()));
    }
    
    private static boolean isISO639Representation(String languageRepresentation) {
        return ("id".equals(languageRepresentation));
    }
    
    private static boolean isLocaleDenotedAsIndonesian(Locale locale) {
        return ("Indonesian".equals(locale.getDisplayLanguage(Locale.ENGLISH)));
    }
}
-------------------------------------------------------------

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Locale id stands for Indonesian: true
Language representation (id) complies with ISO 639: true
Locale representation (id) complies with ISO 639: true

Locale in stands for Indonesian: false
Language representation (in) complies with ISO 639: false
Locale representation (in) complies with ISO 639: false

ACTUAL -
jLocale in stands for Indonesian: true
Language representation (in) complies with ISO 639: false
Locale representation (in) complies with ISO 639: false

Locale in stands for Indonesian: true
Language representation (in) complies with ISO 639: false
Locale representation (in) complies with ISO 639: false


ERROR MESSAGES/STACK TRACES THAT OCCUR :
As you can see, the Locale("id") gets converted to Locale("in"), which is not compliant to ISO 639

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
/* JUnit 3 is needed */
//-----------------------------------------------------------------------
import java.util.Locale;

import junit.framework.TestCase;

public class IndonesianLocaleTest extends TestCase {
    
    public void testCorrectIndonesianLocale() {
        performIndonesianLocaleTestFor(new Locale("id"));
    }

    private void performIndonesianLocaleTestFor(Locale locale) {
        assertTrue(isLocaleDenotedAsIndonesian(locale));
        assertEquals("id", locale.getLanguage()); // FAILS
        assertEquals("id", locale.toString()); // FAILS
    }
    
    private boolean isLocaleDenotedAsIndonesian(Locale locale) {
        return ("Indonesian".equals(locale.getDisplayLanguage(Locale.ENGLISH)));
    }
}

---------- END SOURCE ----------

Comments
No plan to provide new methods only to resolve this. In fact, the test case provided here exactly tries to do the example which is not recommended in getLanguage() method description.
03-07-2013

PUBLIC COMMENTS Backwards compatibility is a fine goal, but if it breaks correctly-written new code (as in this case) it is clearly the wrong decision. This needs fixing - we've hit it on opensolaris.org as well. Bumping bug priority to see if we can get some movement on the bug.
21-07-2009

EVALUATION The reason the way current Java runtime works is for the backward compatibility, which is described in the Locale class's constructors and getLanguage() method description. However, as specified in the bug report 4778440, it has problems for loading resource bundles with the current ISO language code. We need to find a solution for the new ISO code to be used for loading resource bundles, as well as keeping the compatibility.
04-08-2006