BigDecimalAsStringSerializer in NumberSerializer throws IllegalStateException in 2.10

[johanhaleby]

Hi,

I just updated from Jackson (databind) 2.9.7 to 2.10.0 as a part of updating from Spring Boot 2.1.x to 2.2. In my project I depend on jackson-dataformat-hal to generate responses to web requests. After the update to Jackson 2.10 I get the following exception when trying to serialize a field of type BigDecimal:

Caused by: java.lang.IllegalStateException: null
	at com.fasterxml.jackson.databind.ser.std.NumberSerializer$BigDecimalAsStringSerializer.valueToString(NumberSerializer.java:161)
	at com.fasterxml.jackson.databind.ser.std.NumberSerializer$BigDecimalAsStringSerializer.isEmpty(NumberSerializer.java:132)
	at com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:711)
	at io.openapitools.jackson.dataformat.hal.ser.HALBeanSerializer$FilteredProperties.serialize(HALBeanSerializer.java:191)
	... 120 common frames omitted

If I have a look at com.fasterxml.jackson.databind.ser.std.NumberSerializer$BigDecimalAsStringSerializer.valueToStringit looks like this:

@Override
public String valueToString(Object value) {
    // should never be called
    throw new IllegalStateException();
}

but this method seems to be called from com.fasterxml.jackson.databind.ser.std.NumberSerializer$BigDecimalAsStringSerializer.isEmpty(NumberSerializer.java:132) just as the exception implies:

@Override
public boolean isEmpty(SerializerProvider prov, Object value) {
    return valueToString(value).isEmpty();
}

The call to BeanPropertyWriter.serializeAsField(..) in jackson-dataformat-hal looks like this:

for (BeanPropertyWriter prop : state) {
    try {
        prop.serializeAsField(bean, jgen, provider);
    } catch (Exception e) {
        wrapAndThrow(provider, e, bean, prop.getName());
    }
}

where jgen is a JsonGenerator and provider is a SerializerProvider from Jackson 2.10.

Could this be a bug in Jackson Databind or is there something else going on?

[cowtowncoder]

It could be a bug certainly. It would be great to have a reproduction through a real use case (that is, ideally just serializing a bean with BigDecimal field, but with settings that trigger the problem). From isEmpty() call I am guessing this could be related to filtering (via @JsonIncluder or global settings), so it may be easy to reproduce, but obviously existing test suite does not trigger this behavior or problem would have been caught.

[cowtowncoder]

And yes, that call looks... very odd. I do not know how this sequence of calls came to be.
But change was for #2230.

On test case: looks like this would only be triggered if BigDecimal is configured to be written as JSON String?

[cowtowncoder]

I think test could be added to com.fasterxml.jackson.databind.ser.jdk.NumberSerTest, as alternatively configured case of "testNumbersAsString()".

[cowtowncoder]

Was able to reproduce, think I can fix it quite easily.

[johanhaleby]

Great news! Let me know if there is something I can help out with. sön 20 okt. 2019 kl. 05:21 skrev Tatu Saloranta <[email protected]>:

Was able to reproduce, think I can fix it quite easily. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2513?email_source=notifications&email_token=AABNVFIXHTLRIT6WPPT57NTQPPFEXA5CNFSM4JCPJYE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYBM6Q#issuecomment-544216698>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABNVFMAUHDLLISJFQ36H4DQPPFEXANCNFSM4JCPJYEQ> .

-- Sent from my phone

[cowtowncoder]

@johanhaleby I think the only thing would be if you can easily either use 2.10.1-SNAPSHOT or build locally from 2.10 branch, to verify that latest jackson-databind works. I think fix should work as it is quite straight-forward but it is always best if submitter can verify with original setup.