Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serializing locale with underscore, not standard hyphen #1600

Closed
akoshman opened this issue Apr 11, 2017 · 8 comments
Closed

Serializing locale with underscore, not standard hyphen #1600

akoshman opened this issue Apr 11, 2017 · 8 comments
Labels
Milestone

Comments

@akoshman
Copy link

akoshman commented Apr 11, 2017

There were an issue with deserializing locales #1344

But there is still a problem that during serialization Jackson is executing toString() method for locale. According to the official javadoc, toString() must be used for debug purposes. I think it is better to use toLanguageTag() for the serialization since it produces locale represenation with a hyphen as a delimiter:

https://docs.oracle.com/javase/7/docs/api/java/util/Locale.html

@cowtowncoder
Copy link
Member

Ok that sounds plausible I guess.

My main concern here is the backwards compatibility, as usual; if change can be made in a compatible way

@cowtowncoder
Copy link
Member

For what it is worth, there is currently no dedicated serializer for Locale; it does use default ToStringSerializer.

@michaelkrog
Copy link

I experience this is an issue as well in our setup with mixed .NET and Java services.

.NET default is to use a Hyphen and there some of our services expect a Hyphen. Developing a Java-client against these services requires a custom serializer.

@paolobazzi
Copy link

paolobazzi commented Feb 15, 2018

+1 for solving this issue. As workaround we added a custom implementation of the ToStringSerializer using Locale.toLanguageTag()

Could Backward-compatibility be added using a new serialization property (e.g. USE_LOCALE_TO_STRING_SERIALIZATION) or a JsonFormat annotation?

@cowtowncoder
Copy link
Member

@paolobazzi At this point I think the fix needs to go in 3.0, for better or worse. Features are bit coarse-grained for this (I know there are a few datatype-specific ones, but ideally would try to avoid that); and they'd need to go in a new minor version anyway. But 2.9 is likely the last 2.x version.

@cowtowncoder cowtowncoder added this to the 3.0.0 milestone Feb 15, 2018
@paolobazzi
Copy link

Thanks for solving this issue!
Is there an idea when Release 3.0 will be available?

Cheers, Paolo

@cowtowncoder
Copy link
Member

@paolobazzi No idea unfortunately at this point. Big changes still going on so we are far from even the first pre-release version. At earlier, if I had to guess, July/August; but might be closer to end of 2018.

@paolobazzi
Copy link

Thanks for your information!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants