Handle Scala option type (if possible)

[fasterxml]

Handle Scala option type (if possible)

[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.