[loc-en-dev] Backward Compatibility Note

[Naoto Sato]

(7/22/10 2:29 PM), Doug Felt wrote:
>
>
> On Wed, Jul 21, 2010 at 3:17 PM, Naoto Sato <naoto.sato at oracle.com
> <mailto: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.

Sounds reasonable. If the serialized object is read on a prior JDK, it 
would still be compatible.

Naoto

>
>     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.
>
>
>