Collection Serializers do not support `JsonSerialize.Inclusion.NON_EMPTY`

[fasterxml]

Collection Serializers do not support `JsonSerialize.Inclusion.NON_EMPTY`

[cowtowncoder]

Quick note -- related issue for Jackson core is [http://jira.codehaus.org/browse/JACKSON-695].

I'll have to look, I only now realized that it is actually related to the empty value comparison thing.

[cowtowncoder]

One possibly related thing is that JsonDeserializer has getEmptyValue() accessor, used mostly to work around problem with primitive/wrapper value handling. But perhaps similar method should be added in JsonSerializer (with default impl of just retuning null) -- the idea here being that if a non-null value is returned, it can be used for equality comparison to determine if a given value of that type is empty; PropertyBuilder could easily construct a standard checker object that simply calls emptyValue.equals(comparedValue).
This seems like a relatively simple way to achieve extensibility, since registering of deserializers is already fully supported.

[christophercurrie]

I like this plan, though obviously emptyValue.equals(comparedValue) won't work so well if the default emptyValue is null. But in general I like the idea that the serializer can own this logic.

[cowtowncoder]

Yes, although since one can easily return object that is not of expected type (but rather artificial object with equals() redefined), it is possible to also accept null. This is actually how NON_EMPTY comparators for arrays and Collections work -- it is bit of abuse of equals(), but seems acceptable in this case.

This may be a good example where we would have been better off, if original idea (for getEmptyValue() used with JsonDeserializer) had been thought of more broadly. Mea culpa. :)

[cowtowncoder]

Chris -- can you formulate improvement idea in a statement to include in that "plans for 2.0" page? It sounds like the thing to do for 2.0, where we can easily add new methods to JsonSerializer/-Deserializer

[christophercurrie]

Sorry this is late in coming, I haven't had time to think about how to state the idea in my head. The gist of it goes:

Expose the representation of the attributes and qualities of a type separately from the Serializer or Deserializer
that encodes/decodes them.

The basic theory is that the set of representations in JSON is small, so we can define the set of operations on a type that might stand for those representations a priori. This is kind of like a pimped out Bean Descriptor, that has an API that custom types can define. Things like:

• What kind of values does this type encode? Scalar (boolean, numeric, string), Vector, or Map?
• Does this type have a 'null' value, and if so what is it?
• For Scalars:
  • Given an instance of this type, produce the correct scalar value
  • For a given scalar value, produce an instance of this type, if possible.
• For Vectors:
  • Is the length of the vector fixed or variable?
  • What is the 'n-th' value of this vector?
  • What is the type descriptor of the 'n-th' value of this vector?
  • Create a builder for this type that can accept values in order and can construct a valid instance of this type when complete.
• For Maps:
  • is the set of keys fixed or variable?
  • What is the type descriptor for keys?
  • What is the value of key "foo"?
  • What is the type descriptor for key "foo"?
  • Create a builder for this type that can accept keys/value pairs and can construct a valid instance of this type when complete.

With this kind of framework in place, in many cases you might not need a new serializer or deserializer for a type, just a TypeDescriptor, which a standard ScalarSerializer, VectorSerializer, or MapDeserializer could pull values from, and the corresponding Deserializers would use to create builders to feed values into.

Some things get complicated, like Dates. We'd need a way for a TypeDescriptor to express the idea of multiple valid representations, such as numeric or string, some expression of which representation is the default, and an appropriate annotation to override the default. Descriptors that can serialize as a string could optionally support a format string, to allow for type-specific formatting.

I could dive more deeply into detail, but I think I've gone on long enough. Let me know if any of this makes sense.

[cowtowncoder]

I will have to read & think about this. At high (enough) level I think it does make sense.

[cowtowncoder]

Quick note: [JACKSON-695] now implemented for 2.0; JsonSerializer has 'boolean isEmpty(T value)' method, so Scala collection/map/option types can now add support for explicit pruning of values considered empty.

[christophercurrie]

As of 361d4b1 I have specifically added this for Map, Option, and Iterable. I considered adding it for Tuple but rejected it as there is no Tuple0 that would reasonably be empty.