[hibernate-dev] Locale to/from String

Steve Ebersole steve at hibernate.org
Fri Aug 12 22:05:04 EDT 2016

We could also redo our toString support to support "__ch123" if we want.  I
just think its better to standardize if we are talking externalizations.

On Fri, Aug 12, 2016 at 8:47 PM Steve Ebersole <steve at hibernate.org> wrote:

> I have had a comment in LocaleType for quite some time to convert
> fromString handling to use the Locale.Builder introduced in Java 7.  As
> part of the 6.0 work I took a quick look at this.
> I think we handle this incorrectly for certain cases currently.
> Currently we implement toString(Locale) via Locale#toString, where the
> authors specifically say "If both the language and country fields are
> missing, this function will return the empty string, even if the variant,
> script, or extensions field is present (you can't have a locale with just
> a variant, the variant must accompany a well-formed language or country
> code)."
> However in fromString we actually allow for such cases.  Consider this
> test:
> assertEquals(
>         "___ch123",
>         LocaleTypeDescriptor.INSTANCE.toString(
>                 LocaleTypeDescriptor.INSTANCE.fromString( "__ch123" )
>         )
> );
> This actually ends up failing.  The assertion fails.  LocaleTypeDescriptor.INSTANCE.fromString(
> "__ch123" ) does in fact parse us a Locale with no language, no
> country/region and a variant of "ch123".  In fact if I check the Locale
> fields individually they are all set that way.
> However, as per that javadoc note, the call to LocaleTypeDescriptor#toString
> (Locale#toString) returns "".
> So the question becomes what we want to support here.  If the described
> Java behavior is to not allow a Locale with just a variant (no language nor
> country/region) I think we may want to enforce that here too.
> Thoughts?

More information about the hibernate-dev mailing list