[
https://issues.apache.org/jira/browse/LUCENE-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-4021:
--------------------------------
Attachment: LUCENE-4021.patch
Here's the patch: now they round-trip.
Problem 1 was our switch statement on the number of elements:
"For compatibility reasons, two non-conforming locales are treated as special
cases. These are ja_JP_JP and th_TH_TH. These are ill-formed in BCP 47 since
the variants are too short. To ease migration to BCP 47, these are treated
specially during construction. These two cases (and only these) cause a
constructor to generate an extension, all other values behave exactly as they
did prior to Java 7.
Java has used ja_JP_JP to represent Japanese as used in Japan together with the
Japanese Imperial calendar. This is now representable using a Unicode locale
extension, by specifying the Unicode locale key ca (for "calendar") and type
japanese. When the Locale constructor is called with the arguments "ja", "JP",
"JP", the extension "u-ca-japanese" is automatically added.
Java has used th_TH_TH to represent Thai as used in Thailand together with Thai
digits. This is also now representable using a Unicode locale extension, by
specifying the Unicode locale key nu (for "number") and value thai. When the
Locale constructor is called with the arguments "th", "TH", "TH", the extension
"u-nu-thai" is automatically added."
http://docs.oracle.com/javase/7/docs/api/java/util/Locale.html
Problem 2 was the assertEquals, I think like TimeZone we cannot guarantee this.
So simply change the test to use toString(), which is well-defined too:
http://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#toString%28%29
> Locale representations don't round trip from toString->new Locale.
> ------------------------------------------------------------------
>
> Key: LUCENE-4021
> URL: https://issues.apache.org/jira/browse/LUCENE-4021
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Dawid Weiss
> Priority: Minor
> Attachments: LUCENE-4021.patch
>
>
> The script and extensions are not currently parsed. Seems like they were
> added in 1.7 only too so it'll probably require Java-version-specific
> workarounds.
> {noformat}
> public void testLocaleRoundTrip() {
> for (Locale locale : Locale.getAvailableLocales()) {
> String s = locale.toString();
> try {
> Locale back = LuceneTestCase.localeForName(s);
> assertEquals(locale, back);
> } catch (Exception e) {
> System.err.println("Failed roundtrip: " + s + " (" + e.toString() +
> ")");
> } catch (AssertionError e) {
> System.err.println("Not equals: " + s + " (" + e.toString() + ")");
> }
> }
> }
> {noformat}
> Example locales that don't pass.
> {noformat}
> th_TH_TH_#u-nu-thai
> ja_JP_JP_#u-ca-japanese
> {noformat}
> Interestingly, some that do pass the reverse trip are not .equal to their
> originals:
> {noformat}
> Not equals: sr_ME_#Latn (java.lang.AssertionError: expected:
> java.util.Locale<sr_ME_#Latn> but was: java.util.Locale<sr_ME_#Latn>)
> Not equals: sr_BA_#Latn (java.lang.AssertionError: expected:
> java.util.Locale<sr_BA_#Latn> but was: java.util.Locale<sr_BA_#Latn>)
> Not equals: sr__#Latn (java.lang.AssertionError: expected:
> java.util.Locale<sr__#Latn> but was: java.util.Locale<sr__#Latn>)
> Not equals: sr_RS_#Latn (java.lang.AssertionError: expected:
> java.util.Locale<sr_RS_#Latn> but was: java.util.Locale<sr_RS_#Latn>)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
