StringUtils#parseLocaleString(String) with Variant when no Country [SPR-7598]

[spring-projects-issues]

Antonio Mota opened SPR-7598 and commented

This issue is related to, but supersedes, #11228. Given the bugs described in that Jira, I propose the following code:

 
        public static Locale parseLocaleString(String localeString) {
		String[] parts = localeString.split("[_ ]",3);
		String language = (parts.length > 0 ? parts[0] : "");
		String country = (parts.length > 1 ? parts[1] : "");
		String variant = (parts.length > 2 ? parts[2] : "");
		return new Locale(language, country, variant);
	}

Some notes:

It throws a NullPointerException if localeString is null wich conforms with the Locale constructors (??thrown if any argument is null??).

Also, it does no validations, as per the Class description "??Because a Locale object is just an identifier for a region, no validity check is performed when you construct a Locale.??"

---

Issue Links:

• Revise StringUtils.parseLocale(String) for proper handling of corner cases [SPR-16651] #21192 Revise StringUtils.parseLocale(String) for proper handling of corner cases
• LocaleEditor does not work with some locale strings [SPR-8099] #12754 LocaleEditor does not work with some locale strings ("supersedes")
• StringUtils#parseLocaleString(String) does not work for empty locale [SPR-6562] #11228 StringUtils#parseLocaleString(String) does not work for empty locale ("supersedes")

Referenced from: commits cab35aa, 55563c1

1 votes, 3 watchers

[spring-projects-issues]

Juergen Hoeller commented

I've addressed the uncommon variant-without-country case in a pragmatic fashion, using a "#..." part as variant without country if no further token follows. This allows us to properly parse all available locales on the JVM, even "sr__#LATN", closing a gap for #21192... while retaining our lenient parsing of separators for backwards compatibility.