Handle Scala option type (if possible)

[cowtowncoder]

note: re-created from [http://jira.codehaus.org/browse/JACKSON-247], see original issue for more details

---

Initial description:

So, the type of field I'm trying to map is a Scala Option[A] type. You can read some decent introductory stuff on it on various blogs. It's really useful when you have a value that is optional.

The specific case that I'm having a problem with is this Link class

class Link(href: URI, rel: String, length: Option[Long], hreflang: Option[String])

length and hreflang are never null. They are either Some or None. But when serializing, if the value is None, then I don't want to write a field out at all. But, the BeanPropertyWriter will see those values as being non-null and write out the field even if we don't want it to.

---

Comments:

---

Greg Zoller added a comment - 19/Nov/10 5:36 PM

Not sure who is the original requester but their desired approach to have no output for None won't work. Despite their assertion that length and hreflang will never be null, only Some() or None, a generalize json representation of Scala Option types can't make that heroic assumption.

An option is really a trinary value: Some(), None, or null, and a json representation must account for this.

The prototype package released under ticket http://jira.codehaus.org/browse/JACKSON-211 addresses this and handles Option (I think) correctly.

[acruise]

FWIW, lift-json serializes Options as None->Not Present, Some->Present and I haven't seen anyone complaining.

I think you'd be well within your rights to HCF (halt and catch fire ;) when an Option-typed attribute is null. We don't do things that way in Scalaland. The current serialization scheme with empty/value attributes is pretty ugly.

[cowtowncoder]

Ok, I appreciate your help. I am not (yet) a Scala user (just play one at jackson projects :) ), so this is helpful to know.

[advorkovyy]

I think it is fine to serialize null, None and Some(null) as null, Some(x) as x. During deserialization null will become None and x will become Some(x). Yes, serialization and deserialization are not exactly symmetrical in this case, but this is fine since null and Some(null) are rather exceptional cases and are not meant to be useful values for Options.

I do not agree that properties holding None must not be serialized, this is another aspect. None represents missing value, not missing property.

I have coded Option ser/deser using this logic for myself, can share it. I have also support for Scala properties (without @BeanProperty), Scala BigDecimal, BigInt. I plan to add support for Tuples and all Scala collection types using Builders, without JavaConversions. This will preserve unique performance characteristics of each Scala collection type.

[acruise]

By the way, since I posted my message up there, I discovered (and submitted several patches to) Jerkson, which is a Scala wrapper around Jackson that's pretty good.

[advorkovyy]

looks more like what I want and need. will give it a try. thanks!

[cowtowncoder]

Yeah, I was aware of Jerkson which also looks good. I think there is room for both -- benefit of Jackson scala module is mostly that it has bit more extensive data binding support for POJOs. But Jerkson is more Scala oriented which can be good for many use cases.

Btw I think these would be good discussions for mailing list -- wonder if there should be a separate google group for jackson scala module? For now general jackson mailing list should work ok I guess.

[christophercurrie]

Started taking a crack at this. On the surface it looks trivial, but the Module system actually doesn't appear to support the use case. In ObjectMapper#_readMapAndClose, if the current token is VALUE_NULL, then the method just returns null; there's no mechanism for the deserializers to kick in and affect the result.

I haven't been able to find an extension point that can affect this. Tatu, can you weigh in?

[cowtowncoder]

Right, customization options for handling JSON null values are limited, and especially so as root value (things are bit easier for property values). One thing code probably should do is to actually locate root deserializer, and then call 'deserializer.getNullValue()'. This would help with some other cases (for example, if trying to bind to primitive types; maybe not the smartest thing to do, but with auto-boxing one can pass type Integer.TYPE)...

I will file a Jackson request, and will try to also work on issues you already raised (thanks!).

Btw, I really appreciate help with this module; as with Hibernate, I can't really drive this one too much not being an active Scala developer (yet?)

[christophercurrie]

Resoved in commit 70cf50e.