[loc-en-dev] Backward Compatibility Note

[Doug Felt]

On Wed, Jul 21, 2010 at 3:17 PM, Naoto Sato <naoto.sato at oracle.com> wrote:

> 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.
>
> Yes, it should.


> And, what should writeObject() do? Remove the redundant extension or keep
> it?
>
> I expect it should write out the full state of the Locale.


> 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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20100722/6fbe3b36/attachment.html