Change field name serialization without @JsonProperty

[Mark Derricutt]

Hey all,

I have an internal SimpleModule which provides a custom serialiser for some types we use which works great when they're used as values, but not so much when they're keys in a map.

We're serialising out some internal Clojure data structures and keywords toString() as :test, and our custom module corrects that to just test, however, it seems when we have a map with say :count -> 5, I'm still seeing :count being serialised.

Am I correct in that a StdSerializer only works on the value side of things?

I see in DefaultSerializerProvider#_serialize:

  private final void _serialize(JsonGenerator gen, Object value, JsonSerializer<Object> ser, PropertyName rootName) throws IOException {
    try {
      gen.writeStartObject();
      gen.writeFieldName(rootName.simpleAsEncoded(this._config));
      ser.serialize(value, gen, this);

which doesn't seem to serialise the field name at all, is what I want actually possible at all?

Cheers
Mark

---

"The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

[Tatu Saloranta]

On Mon, Aug 5, 2019 at 4:22 PM Mark Derricutt <ma...@talios.com> wrote:
>
> Hey all,
>
> I have an internal SimpleModule which provides a custom serialiser for some types we use which works great when they're used as values, but not so much when they're keys in a map.
>
> We're serialising out some internal Clojure data structures and keywords toString() as :test, and our custom module corrects that to just test, however, it seems when we have a map with say :count -> 5, I'm still seeing :count being serialised.
>
> Am I correct in that a StdSerializer only works on the value side of things?
>
> I see in DefaultSerializerProvider#_serialize:
>
> private final void _serialize(JsonGenerator gen, Object value, JsonSerializer<Object> ser, PropertyName rootName) throws IOException {
> try {
> gen.writeStartObject();
> gen.writeFieldName(rootName.simpleAsEncoded(this._config));
> ser.serialize(value, gen, this);
>
> which doesn't seem to serialise the field name at all, is what I want actually possible at all?

So, from Jackson perspective, handling of POJOs differs a lot from
serializing Maps, and only POJOs have fields/properties in that sense.
All standard rename options apply to POJOs, none for Maps, as well
(although some ignoral settings do work for Maps as well, including
`@JsonIgnoreProperties`). This is mostly because renaming options are
based on static mapping between external (expected) JSON names, and
internal POJO field names; nothing is calculated dynamically based on
content.

So that's one thing. Other part is that custom serializers and
deserializers registered for value types are not used for Map keys:
you can register custom key (de)serializers, but they are separate. In
your case, then, I think it's just matter of registering key
serializers along with value serializers.

-+ Tatu +-

[Mark Derricutt]

On 7 Aug 2019, at 7:52, Tatu Saloranta wrote:

In
your case, then, I think it's just matter of registering key
serializers along with value serializers.

That works a treat! Cheers - saves me recursing thru the data structure manually remapping keys to strings :)

[Tatu Saloranta]

On Tue, Aug 6, 2019 at 4:03 PM Mark Derricutt <ma...@talios.com> wrote:
>
> On 7 Aug 2019, at 7:52, Tatu Saloranta wrote:
>
> In
> your case, then, I think it's just matter of registering key
> serializers along with value serializers.
>
> That works a treat! Cheers - saves me recursing thru the data structure manually remapping keys to strings :)

Good!

This is one of more confusing parts of Jackson, and if I was to
redesigns things from scratch, would probably make it easier to
support both value and Map key handling from same implementations
(there are some limitations to key part as JSON requires keys to be
Strings always, can't do structured values etc), so that
out-of-the-box support was wider, and custom handlers easier.

But at least once you know how things work support is just little bit more work.

-+ Tatu +-

[Mark Derricutt]

On 7 Aug 2019, at 11:06, Tatu Saloranta wrote:

But at least once you know how things work support is just little bit more work.

Yep - was just adding a boolean flag to my construction to call writeFieldName vs writeString.

Was nice that it was a fairly trivial fix as well.