Add inclusion feature to avoid serializing (non-null) empty collection

I tried something like that, which does not work (Jackson 1.4.2).
My custom serialize is not called.
I've probably done something bad but cannot find it...

 
        ObjectMapper mapper = new ObjectMapper();
        AnnotationIntrospector primary = new JacksonAnnotationIntrospector();
        AnnotationIntrospector secondary = new JaxbAnnotationIntrospector();
        AnnotationIntrospector pair = new AnnotationIntrospector.Pair(primary, secondary);
        mapper.getDeserializationConfig().setAnnotationIntrospector(pair);
        mapper.getSerializationConfig().setAnnotationIntrospector(pair);
        mapper.getSerializationConfig().disable(SerializationConfig.Feature.INDENT_OUTPUT);
        mapper.getSerializationConfig().enable(SerializationConfig.Feature.USE_ANNOTATIONS);
        mapper.getSerializationConfig().enable(SerializationConfig.Feature.WRAP_ROOT_VALUE);
        mapper.getSerializationConfig().setSerializationInclusion(JsonSerialize.Inclusion.NON_NULL);

        CustomSerializerFactory sf = new CustomSerializerFactory();
        sf.addGenericMapping(Collection.class, new JsonSerializer<Collection>() {

            @Override
            public void serialize(Collection value, JsonGenerator jgen, SerializerProvider provider)
                    throws IOException, JsonProcessingException {
                if (value.size() != 0) {
                    ContainerSerializers.CollectionSerializer.instance.serialize(value, jgen, provider);
                }
            }
        });
        mapper.setSerializerFactory(sf);

That does look valid. I will figure out why it is not working; as far as I can see, it should.

Ok, there is a fundamental problem with this approach (suppressing output from custom collection serializer): serializer MUST write a JSON value; otherwise resulting JSON may be invalid.
Consider case where collection is a value of property – JSON property name is output, and there has to be some value.
It may be 'null', empty Strings, empty JSON Array, but can not be missing.

So this would not work for intended use. A variation might work that used method null-suppression, however: using
@JsonSerialize(include=Inclusion.NON_DEFAULT)
should suppress output. But if (and only if!) a concrete type was used: this because abstract types can not be instantiated, so there can not be a default value (default is defined as instance constructed using no-args constructor).

I did test override functionality itself, and as far as I can see, it works (see unit test src/test/org/codehaus/jackson/map/ser/TestCustomSerializers.java in trunk).

This is also problematic for global feature. New inclusion enum value might work from user perspective; challenge is in actually implementing it.

Ok, that's clear now I realize we have only the value...

By using NON_DEFAULT with concrete type, you mean, for instance, modifying my beans to make a property an ArrayList instead of a List? Getter/setter or property level (property would be better but I guess due to limitations with introspection, it is getter/setter?
I'm going also to look at my beans as the default behavior seems perfectly right to me (an empty collection resulting in an empty array).

Actually, now that I think about it, what you need is just to initialize collection field to be empty, not null:

class MyBean {
Collection<String> ids = new ArrayList<String>(); // or from constructor
// accessors are fine too
}

and then that Collection is the default value, which can be suppressed.

I'd like to see this implemented, although I'm currently using Inclusion.NON_NULL so I guess I'd need an inclusion feature that handles both non nulls and empty collections (or perhaps a way to specify multiple inclusions).

I wonder – since NON_DEFAULT does work for concrete type, maybe this could be handled by just extending logics used to determine default value. Basically such that types like List.class would have default values (even though being non-concrete one can not instantiate them), by using default types.

Implemented as the first new 1.9 feature. Relatively simple to add, not yet sure if it's hacky or elegant solution...

Sounds cool. Will this feature be also available for custom serializer?

Example: An object that under some circumstances will be serialized to

{
  "id" : "whatever",
  "key" : {}
}

where the {} are coming from a custom serializer.

I wuold like either have an option from inside the serializer to stop the serialization of this object (return code or throwing special exception)
or having your implementation also filtering this empty object out:

{
  "id" : "whatever"
}

(Inclusion.NON_DEFAULT is not working, although the empty serialization is the default )

Jan

It should be easy to test, but I think that since check is done before calling serializer for a property it should indeed work even if a custom serializer is used.