Deserializes "null" to "0.0" in big-D Double

When a bean has a big-d Double, and the value is null, it gets decoded as 0.0 instead. The two are not equivalent.

This code shows the problem:

package test;

import com.fasterxml.jackson.jr.ob.JSON;

import java.util.List;

public class DoubleTest {

    private Double value;

    public static void main(String[] args) throws Exception {
        for (var testInput: List.of(
            "{\"value\": 1.0}", "{\"value\": 0.0}", "{}", "{\"value\": null}")) {
            System.out.println("Input JSON: " + testInput + "  -  Output bean: " + JSON.std.beanFrom(DoubleTest.class, testInput));
        }
    }

    public Double getValue() {
        return value;
    }

    public void setValue(Double value) {
        this.value = value;
    }

    public @Override String toString() {
        return "DoubleTest[" + value + "]";
    }
}

Output:

Input JSON: {"value": 1.0}  -  Output bean: DoubleTest[1.0]
Input JSON: {"value": 0.0}  -  Output bean: DoubleTest[0.0]
Input JSON: {}  -  Output bean: DoubleTest[null]
Input JSON: {"value": null}  -  Output bean: DoubleTest[0.0]

The fourth JSON object should be deserialized the same as the third.

[bill-phast]

I’m actually on 2.12.1, sorry I didn’t know 2.12.2 was out. I found a workaround; add a reader/writer provider that provides this object when a reader for Double.class is needed:

    /**
     * Jackson Jr. by default converts null to 0.0. We need to keep it as null.
     */
    private static final ValueReader DOUBLE_READER = new ValueReader(Double.class) {
        @Override
        public Object read(JSONReader reader, JsonParser jsonParser) throws IOException {
            return jsonParser.currentToken() == JsonToken.VALUE_NULL ? null : jsonParser.getValueAsDouble();
        }
    };

But it seems it would be best to make this workaround unnecessary, to just preserve nulls. (I have verified that yes, Integer, Boolean, Float, and Character, all have this problem, all can be fixed by the same workaround technique. I guess I have some of complex beans.)

[cowtowncoder]

2.13 branch is open, so PRs are possible against.

Unfortunately I don’t think I will have time to work on this problem in near future. I think that to make this change, new type constants would be needed for standard deserializers (one for each primitive/wrapper case), and then matching changes to ValueReaders. Not necessarily very difficult, just quite a bit of work.