Allow "Serialize as POJO" using `@JsonFormat(shape=Shape.OBJECT)` class annotation

[hesamwls]

I read here http://www.cowtowncoder.com/blog/archives/2013/10/entry_482.html that @JsonFormat(shape=Shape.OBJECT) must work for both collection and map types but my tests shows it doesn't work for a class that implements Map Interface.
some digging in code approved my initial guess as there's no checking for JsonFormat in BasicSerializerFactory.buildMapSerializer unlike buildCollectionSerializer method.
now I am not sure that blog is official or not, but is there any technical reason to not implement this feature for Map or it's just forgotten?!

[cowtowncoder]

No reason beyond bug or omission. I think blog entry is incorrect here; since Maps are already serialized as JSON Objects, so format override would not make much sense here.

But perhaps you are thinking more about "serialize as POJO" for Maps? I am not sure what'd be suitable override there.

[hesamwls]

yes, "serialize as POJO" was my understanging of @JsonFormat(shape=Shape.OBJECT) but now I see what's going on. I know maps are inherently equivalent to Json objects, but maybe when we say "serialize this with Object shape", what comes to mind is more like "serialize with a general serializer".
can't you just do the same you did to collections? jump of SpecialSerializer (CollectionSerializer in that case) and let more general serializer do the job?
anyway I think the logic behind necessity of this feature for Collections (custom Implementations) applies for Map too and it's good to have this feature for maps.

[cowtowncoder]

It's not that "serialize as POJO" is not doable (it is); it's more that use of @JsonFormat here would not be consistent, since default is already to "serialize as JSON Object". Format/shape here strictly mean kind of output; whereas what you want has more to do with kind of information that is included.

So, it'd be necessary to know proper way to indicate such variant.

[hesamwls]

ok, I see your point, although I think it's not an incostitency since the result is still Json Object if we use POJO serializer either, but I agree that there would be some ambiguity.

[tj-recess]

+1
Any ETA on this?

[cowtowncoder]

I don't think anyone is working on this at this point.
It could be added in 2.7 if a patch is contributed.

Now, similar to my comment on an issue related to Map.Entry, what is needed here is the ability to also indicate "Serialize as expected, not as POJO". Use of Shape.ANY could work on short term, although for 2.7 could consider adding option of Shape.NATURAL, to indicate that default behavior (something consider most natural) should be used, whatever that is. It would be overloaded semantically, but would work ok here.

[cowtowncoder]

FWIW, #865 is the related issue.

[cowtowncoder]

This is implementable at this point, considering there's JsonFormat.Shape.NATURAL to indicate "serialize Map as JSON Object, but not as POJO", and we can interpret Shape.OBJECT to then mean "serialize as POJO".

The reverse side of accepting such POJO may be tricky to implement, but then again should be doable.

[cowtowncoder]

Ok: easy part is implemented so that class annotation like so:

@JsonFormat(shape=JsonFormat.Shape.OBJECT)
@JsonIgnoreProperties({ "size" })
public class MyStrings {
   public int getCount() { 
      return size();
   }
   public Collection<String> getValues() {
      return values();
   }
}

would produce serialization like:

{ "count" : 3,
   "value" : [ "a", "b", "c" ]
}

Note that that this handling only support class-annotations (including mix-ins); per-property overrides are not supported as that is surprisingly difficult to support at this point. If support for property overrides is needed a new issue needs to be filed (also affected: Map.Entry which has similar limitation).