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 <st...@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? > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
