[loc-en-dev] Backward Compatibility Note

[Yoshito Umaoka]

Hi folks,

Belows is the draft contents for "compatibility note" for submitting the 
proposal. If you find any issues or have something to add, please reply 
to this message. I'm expecting that Steven will consolidate inpputs and 
update the contents.

-Yoshito

------------------------
1. Locale#toString()

Locales supported by the current version of Java (Locales returned by 
Locale.getAvailableLocales()) still return the exact same String 
representation by toString() method for exact two exceptions. These 
exceptions are Locale("ja", "JP", "JP") and Locale("th", "TH", "TH"). 
With the new proposal, toString() returns "ja_JP_JP_#u-ca-japanese" and 
"th_TH_TH_#u-nu-thai".

Although a String returned by this method might not represent all of 
Locale's field information (for exmaple, Locale without languag/country, 
but non-empty variant returns empty String), some Java application may 
rely on toString() to get field information. For these two Locales, 
typical assumption (language + '_" + country + '_') is still applicable. 
When such implementation tries to get the variant field, they will be 
"JP_#u-ca-japanese" and "TH_#u-nu-thai". So it may return false result.

However, these two Locales are never used as a system default Locale 
(unless you explicitly specify -Duser.variant=xxxx). Also, the proposed 
representation append the extra part as look like yet another variant 
subpart, so the common locale string truncation algorithm (chopping out 
segments from right) still reasonably works.

2. Equality of two Locales

With the current Java implementation, if two Locales have the same 
language, country and variant, these two Locales are equal. This 
assumption is no longer true with the new proposal (script/extensions 
must be also same). However, this assumption is still true for all 
currently supported Locales. Two Locales not satisfying the assumption 
could be generated only when a user call new proposed APIs (such as 
Locale.forLanguageTag(String) or Builder APIs), In addition to this, 
equality of two Locales should be checked by Locale#equals(Object), 
which is updated to compare script/extensions as well. Therefore, we do 
not think any backward compatibility problems arise with this change.

3. ResourceBundle.Control#getCandidateLocales(String, Locale)

List of Locales generated by the proposed default implementation of 
getCandidateLocales(String, Locale) will change only for Chinese and 
Norwegian. This change is intended for allowing users to package bundles 
cleanly. For a Chinese (or a Norwegian) Locale, the new proposed 
behavior inserts some extra Locales in the result. However, candidate 
Locales generated by the current Java implementation will be still 
appeared in the list in the original ordering even with the new proposed 
implementation. For example, for a given request Locale "zh_CN", extra 
entries with script "zh_Hans_CN" and "zh_Hans" are inserted, but still 
contains "zh_CN", "zh" and ROOT in this order. Because a Locale with 
script cannot be created by the current Java implementation, it is 
really unlikely that a user has two different sets of bundles - one 
group including script / another group without script. Therefore, the 
behavior change discussed here does not introduce any practical 
compatibility problems.

4. ResourceBundle.Control#toBundleName(String, Locale)

A Locale with non-empty script is mapped to a bundle name with suffix 
_<lang>_<script>. The current implementation may consider the second 
suffix subtag would be a country. However, script is always in 
4-letter/title case and country(region) must be always two-letter. So 
it  is not possible to mix them up unless a user specifies 4-letter 
country in the existing Locale constructor (and it's illegal even now - 
the existing implementation just does not check the validity). 
Therefore, this concern is ignorable.