JDK-4140555 : JDK uses "iw" for Hebrew instead of the new ISO standard "he"
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.1.6,1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_2.5.1,solaris_9
  • CPU: generic,other,sparc
  • Submitted: 1998-05-20
  • Updated: 1999-01-15
  • Resolved: 1999-01-15
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.1.7 b01Fixed
Related Reports
Duplicate :  
Duplicate :  
Classes.zip has DateFormatZoneData_iw.class and
LocaleElements_iw.class files, but not DateFormatZoneData_he.class and
LocaleElements_he.class files. "iw" is the old ISO-639 language
abbreviation for Hebrew and "he" is the new one. Windows NT uses the
new ISO abbreviation as opposed to the old. With JDK 1.1.5, if the
Hebrew locale is selected as the default locale via Control Panel
Regional Settings, Java returns "he" instead of "iw".
So, in 1.1.5, the resource files DateFormatZoneData_iw.class and
LocaleElements_iw.class were misnamed. If you ran JDK 1.1.5 FCS or
1.1.6B, and asked for locale info, you would get an answer of "he",
even though the resource files had the "iw" suffix.
Now, from JDK 1.1.6B and onwards, when you set the Regional Setting in
WinNT to Hebrew, the default locale now comes back as "iw" (1.1.6E) as
opposed to "he" (1.1.6B, 1.1.5FCS, etc.).
Since the new ISO code for Hebrew is "he", Java should use "he" as the
locale abbreviation and as a resource filename suffix.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.1.7 FIXED IN: 1.1.7 INTEGRATED IN: 1.1.7 1.2fcs

PUBLIC COMMENTS JDK should support "he" for Hebrew as well as "iw"

EVALUATION The class java.util.Locale uses the old ISO 639 language codes, in order to retain compatibility with previous JDK releases. However, if you construct a Locale object using one of the new codes, it works because the constructor converts it to a compatible old code. New codes thus work fine throughout the API, and nothing in the implementation or data files needs to change. It doesn't matter what Windows (or any other underlying platform) uses as the code as long as the VM determines the language code properly on startup. One other gotcha is that when comparing Locale objects for equality with specific languages, you can't do this: // WRONG if (locale.getLanguage().equals("he")) ... You have to create locales and compare them: // RIGHT if (locale.equals(new Locale("he", ...))) ... alan.liu@eng 1998-06-05 This is not a bug for the reasons explained above; I'm closing it laura.werner@eng 1998-07-09