Alexey, got it regarding "null" string, thank you.
Can you elaborate on non-null default values? Is it only for primitive
types, or something else?
Anyway, can we omit fields with default values? I have seen some
serializers that work this way.
Pavel.
On Thu, Jun 16, 2016 at 1:05 PM, Alexey Kuznetsov <akuznet...@gridgain.com>
wrote:
> Pavel, we cannot omit them.
>
> Because if JSON will be transformed back to Java and some java field has
> not null default value that will lead to not correct de-serialization in
> this case.
>
> On Thu, Jun 16, 2016 at 4:54 PM, Pavel Tupitsyn <ptupit...@gridgain.com>
> wrote:
>
>> Why do we even write null fields? Can we just omit them?
>> This will be faster, more compact, and less ambiguous.
>>
>> Pavel.
>>
>> On Thu, Jun 16, 2016 at 12:51 PM, Denis Magda <dma...@gridgain.com>
>> wrote:
>>
>>> This looks strange. Definitely for consistency reasons it makes sense
>>> that all ‘null’ objects including string are serialized as “null”.
>>>
>>> In regards to the compatibility stuff I think it can be resolved
>>> somehow.
>>>
>>> —
>>> Denis
>>>
>>> On Jun 16, 2016, at 12:15 PM, Alexey Kuznetsov <akuznet...@gridgain.com>
>>> wrote:
>>>
>>> Hi All!
>>>
>>> I'm working on migrating from outdated json-lib to Jackson issue
>>> IGNITE-3277 [1] and found that previous library serialize null strings as
>>> "" and null objects as "null", for example:
>>> {"a": "", "b": null}
>>>
>>> How about to serialize all values as "null" ?
>>> In this case we would definitely know that in Java before serialization
>>> to JSON was really NULL, not empty string.
>>>
>>> But this may break compatibility in some cases.
>>>
>>> Thoughts?
>>>
>>>
>>> 1. https://issues.apache.org/jira/browse/IGNITE-3277
>>>
>>> --
>>> Alexey Kuznetsov
>>> GridGain Systems
>>> www.gridgain.com
>>>
>>>
>>>
>>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>
