[
https://issues.apache.org/jira/browse/LUCENE-6978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15113110#comment-15113110
]
Uwe Schindler commented on LUCENE-6978:
---------------------------------------
Issue should be fixed now. The problem is the non-always-working forbidden API
Locale.toString(). The DIH test cases used string concat with
Locale.getDefault(). This should work in most cases, but "nn-NO" is a special
case. This Locale only exists in the list of available locales with a different
(outdated) name, so the backwards-compatibility layer does not catch it.
The problem is generally: We should remove support for the "old" and no longer
supported by Java Locale syntax in DIH and morphlines. But this would be
separate issue for 6.0 only.
Thanks [~steve_rowe] for reporting this!
> Make LuceneTestCase use language tags instead of parsing locales by hand
> ------------------------------------------------------------------------
>
> Key: LUCENE-6978
> URL: https://issues.apache.org/jira/browse/LUCENE-6978
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/test-framework
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 5.5, Trunk
>
> Attachments: LUCENE-6978-5x.patch, LUCENE-6978.patch,
> LUCENE-6978.patch, LUCENE-6978.patch
>
>
> Since we are on Java 7, the JDK supports standardized language tags as
> identifiers for Locales. Previous versions of JDK were missing a constructor
> from {{Locale#toString()}} back to a locale, so we had our own, which was
> broken several times after the JDK changed their Locale internals.
> This patch will do the following:
> - When printing the reproduce line, it will use {{Locale#getLanguageTag()}},
> so you can identify the locale in standardized form. Most notable change is
> (next to more flexibility around asian languages) the change away from
> undescores. So it prints "en-US", not "en_US".
> - The code that parses a locale uses Locale's Builder and sets the language
> tag. This will fail if the tag is invalid! A trap is
> {{Locale#forLanguageTag}}, because this one silently returns root locale if
> unparseable...
> - The random locale is choosen from all language tags, which are extracted
> from the JDK as a {{String[]}} array.
> I would also like to place {{Locale#forLanguageTag}} on the forbidden list
> and disallow directly calling {{Locale#toString()}}, the latter is legacy API
> (according to Java 7 Javadocs). This would fail code that calls toString()
> directly, e.g. when formatting stuff like {{"my Locale: " + locale}}. Of
> course we cannot catch all bad uses.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
