Support for BCP 47 `java.util.Locale` serialization/deserialization

[abrav9595]

Describe the bug

Locale with BCP 47 extensions are not serialized / de-serialized as expected using ObjectMapper.

Version information

Which Jackson version(s) was this for?
All Jackson versions.

To Reproduce

If you have a way to reproduce this with:

Brief code sample/snippet: include here in pre-formatted/code section

Locale locale = Locale.forLanguageTag("en-US-x-debug");
// ^^^ above locale will have x-debug as extensions
// This locale is a BCP 47 compliant locale.

ObjectMapper objectMapper = new ObjectMapper();

String serializedLocale = objectMapper.writeValueAsString(locale);
// ^^^ Will be en_US-#x-debug. Conforms to toString() method of Locale.
// This is not correct. There is a rogue # is added before extensions. 

Locale deserializedLocale = objectMapper.readValue(serializedLocale, Locale.class); 
// ^^^ Due to the rogue # before the extensions, when we de-serialize it, the extensions get added as a Variant instead of extensions.

Longer example stored somewhere else (diff repo, snippet), add a link

N/A. Reproducible with the above piece of code.

Textual explanation:

• forLanguageTag locale is used to create a locale object from a BCP 47 compliant locale string. The x-debug gets added as extensions in the Locale.
• However, when we use ObjectMapper to serialize the string, objectMapper uses toString() method of locale to convert it to String.
• As Per Locale Javadocs, for BCP 47 locales, we must be using toLanguageTag() and forLanguageTag() instead to convert to / from String.
• Due to this, when we try to de-serialize this malformed Locale, the x-debug gets added as a Variant instead of extensions, which is not expected.

Expected behavior

• BCP 47 extensions should be added as extensions and not as Variants when serializing and de-serializing.

Additional Details

• Due to this drawback, we are forced to write our own serializer / de-serializer. It would be nice if ObjectMapper provides us a Module which does this for us.

[cowtowncoder]

Sounds like we have sub-optimal behavior; would be great to improve handling.
One possible complication is between addressing this only on deserializer (backwards compatible) vs changing serialization (and possibly deserialization) (backwards incompatible -- but probably ok for a new minor release)

I think this is something that might be relatively easy to support so marking as "good first issue".

[abrav9595]

@cowtowncoder Thanks for responding to this issue. Would it be a good idea to create a separate module for BCP 47? For clients who want to use BCP 47 can register this new LocaleModule ? Not sure if this is a good idea though. Would love to know your thoughts.

[cowtowncoder]

I often recommend new modules for additions, but in this case it seems like bit of an overkill, if it only affects handling of one JDK class. Especially if it was possible to address this wrt all users in core jackson-databind.

[praneethjreddy]

@cowtowncoder , Can I pick this up? Looks like we need to write custom serializer/de-serializer for java.util.Locale class

[cowtowncoder]

@praneethjreddy Sure. I do think we have custom (de)serializer already, but it might be part of a multi-type (de)serializer... let me look.

Ok, so:

• for deserialization, it's FromStringDeserializer
• for serialization, basic ToStringSerializer is used (which as per name only calls Locale.toString())

So, it may be necessary to have separate serializer implementation if deserializer-only handling can not be made to work.

[cowtowncoder]

CLA received for the PR; hoping to review and merge the fix RSN!