A DESCRIPTION OF THE REGRESSION :
Problems with Hebrew ('he') Resource Bundles

When using the 'he' Locales (and others mentioned in Locales documentation) different Resource Bundles and other Locale sensitive data are getting used from earlier JDKs compared to those getting used by JDK-b70.

We let the user select from the available Locales and some users have permission to dynamically create translations. For Hebrew in JDK 1.5 these translations end up under the iw Locale while in JDK 1.6 these are ending up under the 'he' Locale. We also allow the user to select many languages so that if a translation is not available in their 1st choice of Language then their next choice is searched etc., hence we also use different routines for locating Locale sensitive data than the way ResourceBundle does.

For this reason in order to make our code work against both JDKs 1.5 and 1.6 we would now need to hard code all the equivalent Locales in order to check each of them (obviously not a good solution).

Placing the 3 Resource Files listed below in the directory where Test.java is compiled to and running the Test demonstrates some of these problems.

As a workaround: whenever using a selected Locale check it's Language and replace it with it's 1.5 equivalent.

Suggestion for improved compatability with more flexibility:
Starting with the 1.5 code:
- add Locale getInstance(...) methods to Locale such that passing in 'he' or 'iw' will both return the 'he' Locale
- add Collection<Locale> getAvailableInstances() method to Locale which will return all the current Locales (ie 'he' and not 'iw')
- add Collection<Locale> getAliases() method to Locale which for 'he' would return 'iw' and vice versa
- deprecate the Locale constructors and the getAvailableLocales() methods so that code that does not take advantage of the new codes will still work but developers will know that they should change their code in order to use the new codes (and hence any future ones as well).
 
Other classes such as ResourceBundle and Code done by non Sun Developers can then use the getAliases() method and other methods in order to do what they need to do without breaking any existing applications.

REPRODUCIBLE TESTCASE OR STEPS TO REPRODUCE:
----- Resources_iw.properties -----
filename=Resources_iw.properties
message=ש××ם ×¢××ם

----- Resources_he.properties -----
filename=Resources_he.properties
message=Hello World

----- Resources.properties -----
filename=Resources.properties
message=Hello World

----- Test.java -----
import static java.lang.System.*;
import java.util.*;

public class Test {
  public static void main(String[] args) {
    List<Locale> list = Arrays.asList(Locale.getAvailableLocales());
    Locale selectedLocale = list.get(list.indexOf(new Locale("iw", "", "")));
    out.println("Selected Locale: " + selectedLocale);
    ResourceBundle bundle = ResourceBundle.getBundle("Resources", selectedLocale);
    out.println("Filename: " + bundle.getString("filename"));
    out.println("Message: " + bundle.getString("message"));
  }
}

RELEASE LAST WORKED:
5.0 Update 6

RELEASE TEST FAILS:
mustang-b70

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Selected Locale: iw
Filename: Resources_iw.properties
Message: ש××ם ×¢××ם

ACTUAL -
Selected Locale: he
Filename: Resources_he.properties
Message: Hello World

OBSERVED APPLICATION IMPACT:
In our application (and I am sure many others as well) text is displayed in the wrong language.
Also the dynamic creation of Resource Files and other Locale sensitive data is causing different files to be created / modified in JDK 1.5 to JDK 1.6 hence we are ending up with some translations under the 'iw' Locale and others under the 'he' Locale causing much confussion (our Clients send information to shared Servers).

If this problem does not get fixed developers will need to use workarounds such as hard coded checks to each of the new Locale codes and replacing them with the old ones in order to make the Applications work both on JDKs 1.5 and 1.6.

If the end users do not update their Clients before switching to 1.6 then they will encounter these translation problems.

Release Regression From : mustang
The above release value was the last known release where this
bug was known to work. Since then there has been a regression.