atom feed4 messages in org.codehaus.jackson.userRe: [jackson-user] serialization of I...
FromSent OnAttachments
David LandisMay 11, 2012 2:10 pm 
Tatu SalorantaMay 11, 2012 10:01 pm 
David LandisMay 13, 2012 11:14 am 
Tatu SalorantaMay 13, 2012 9:16 pm 
Subject:Re: [jackson-user] serialization of Iterable uses BeanSerializer
From:Tatu Saloranta (
Date:May 11, 2012 10:01:36 pm

On Fri, May 11, 2012 at 2:10 PM, David Landis <> wrote:


I have recently upgraded to Guava 12 and when Jackson serializes the new FluentIterables it uses the BeanSerializer resulting in something like:

{empty: false}

I have traced the code to discover this is because Gauva's new FluentIterable has a "Java bean-ish" method called isEmpty so Jackson think it should use the BeanSerializer. Before Guava 12, they would use other implementations of Iterable and Jackson would correctly use another serializer (I believe called IterableSerializer).

Here is the code in BeanSerializerFactory:

               /* And this is where this class comes in: if type is not a                 * known "primary JDK type", perhaps it's a bean? We can still                 * get a null, if we can't find a single suitable bean property.                 */                ser = findBeanSerializer(prov, type, beanDesc, property);                /* Finally: maybe we can still deal with it as an                 * implementation of some basic JDK interface?                 */                if (ser == null) {                    ser = findSerializerByAddonType(config, type, beanDesc, staticTyping);                }

It gives precedence to the BeanSerializer even for Iterables and Iterators. This seems arguable to me but perhaps I am missing something (very possible) :)

Does anyone have an opinion on whether this is correct or incorrect behavior from Jackson? In other words when would someone actually *want* to serialize a subclass of Iterable as a bean instead of an Iterable?

Thanks and by the way Jackson has been great so far for my project so kudos to all the contributors.

Iterable is one of those nasty edge cases, where I am not sure. It is quite often added as convenience thing for otherwise "bean-like" objects. But obviously there are other cases where the thing really is a collection. One possibility would be to add a flag indicating precedence. Or maybe there is another heuristic (no accessors, or at most "empty"... bit hacky, but Collection itself has that)

However, maybe we can work around the problem by adding handling in [], which can specifically indicate that handling should be done as Iterable? One possible concern is of course how to do versioning (wrt. which guava version(s) module should supported.

-+ Tatu +-