DecimalNode type not retained during JDK serialization, deserialization

[victornoel]

Describe the bug

When a DecimalNode is cloned via serialization (serialized then deserialized), the clone is not equal to the original.

I know there are a lot of issues related to BigDecimal in jackson, but I don't think I have seen one about this. Don't hesitate to close it if there are other planned/tracked issues that covers this :)

Version information

2.12.1

To Reproduce

    @Test
    public void should_properly_deserialize_decimal_node() {
        var node = new ObjectMapper().getNodeFactory().numberNode(BigDecimal.ONE);
        Assert.assertTrue(node instanceof DecimalNode);
        var clone = clone(node);
        Assert.assertTrue(clone.equals(node));
        Assert.assertTrue(node.equals(clone));
    }

    @SuppressWarnings("unchecked")
    private <T> T clone(T original) {
        try(var baos = new ByteArrayOutputStream(); var oos = new ObjectOutputStream(baos)) {
            oos.writeObject(original);
            try (var bais = new ByteArrayInputStream(baos.toByteArray()); var ois = new ObjectInputStream(bais)) {
                return (T) ois.readObject();
            }
        } catch (Exception e) {
            throw new IllegalArgumentException(e);
        }
    }

[cowtowncoder]

Thank you for reporting this, @victornoel ! I can see how this might happen, and you are right it is different/not yet reported.

Problem I think is due to JDK serialization of JsonNode basically serializing as JSON, which does not encode actual type information at all -- and when reading back, type might not match.
And come to think of it, some aspects of precision might rely on textual representation as well.

Alternatively this could also be related to the fact that JsonNodeDeserializer only supports targeted reading for ObjectNode and ArrayNode (I think), so even if asked to deserialize as DecimalNode, result might not be that but whatever is "default" JsonNode representation used for floating-point numbers.

I wish I had time to dig into this; seems like there are ways to go about it. Ideally it would "just work", of course.
So leaving open for someone to work on when time allows, interest is piqued.

[cowtowncoder]

Hmmh. Ok, what is happening is that BigDecimal.ONE, 1, gets serialized as JSON value 1 on serialization.
And gets deserialized as IntNode because, well it is an integral JSON number.

This is due to my deciding to use a compact & light-weight format for serialization of JsonNodes: JSON.
It results in serialization sizes well below what default JDK serialization logic would produce (at least for small graphs).
But it does not always retain the exact Object type as shown here.

I think I'll consider it a flaw but one that probably will not be fixed: effort to create alternate parallel encoding schema that would retain type seems rather expensive for benefits. In general intent with JsonNode really is to handle it as JSON representation.