[LUCENE-6978] Make LuceneTestCase use language tags instead of parsing locales by hand

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 5.5, 6.0
• Component/s: modules/test-framework
• Lucene Fields: New
• Assignee: Uwe Schindler
• Reporter: Uwe Schindler
• Created: 15/Jan/16 12:58
• Updated: 28/Aug/22 14:48
• Resolved: 15/Jan/16 23:30

Description

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.

Issue Links

• is related to: SOLR-9430 Locale in <propertyWriter in DIH is looked up based on Locale displayName (language tag "en-US" or legacy name "en_US" does not work, English works)