[loc-en-dev] Backward Compatibility Note

[Naoto Sato]

Actually reading the "Equality of two Locales" section reminds me that 
Locale.readObject() should also append extensions for ja_JP_JP and 
th_TH_TH as well as the constructors.

And, what should writeObject() do? Remove the redundant extension or 
keep it?

Naoto

(7/19/10 11:41 PM), Yoshito Umaoka wrote:
> 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.