OutOfMemoryError when writing BigDecimal

When I’ve enabled the WRITE_BIGDECIMAL_AS_PLAIN setting on Jackson 2.7.5, Jackson will attempt to write out the whole number, no matter how large the exponent.

For example, the following code:

ObjectMapper mapper = new ObjectMapper().enable(JsonGenerator.Feature.WRITE_BIGDECIMAL_AS_PLAIN);
mapper.writeValueAsString(new java.math.BigDecimal("9.223372E+1010671858"));

triggers the exception:

java.lang.OutOfMemoryError: Java heap space
  at java.lang.AbstractStringBuilder.<init>(AbstractStringBuilder.java:68)
  at java.lang.StringBuilder.<init>(StringBuilder.java:101)
  at java.math.BigDecimal.toPlainString(BigDecimal.java:2964)
  at com.fasterxml.jackson.core.json.WriterBasedJsonGenerator.writeNumber(WriterBasedJsonGenerator.java:690)
  at com.fasterxml.jackson.databind.ser.std.NumberSerializer.serialize(NumberSerializer.java:45)
  at com.fasterxml.jackson.databind.ser.std.NumberSerializer.serialize(NumberSerializer.java:19)
  at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:130)
  at com.fasterxml.jackson.databind.ObjectMapper._configAndWriteValue(ObjectMapper.java:3612)
  at com.fasterxml.jackson.databind.ObjectMapper.writeValueAsString(ObjectMapper.java:2980)
  ... 23 elided

I know technically Jackson is doing what you’re telling it to do (so if you don’t feel this is an issue feel free to close it). But it would be nice if WRITE_BIGDECIMAL_AS_PLAIN set a reasonable length on the number, so as not to leave users open to denial of service vulnerabilities.

(Actually, I think this might technically be an issue in jackson-core; let me know if I should resubmit.)

[gmethvin]

@cowtowncoder I guess it really depends on how people use that setting. For me a maximum of ten zeroes would be fine, but there’s no limit that’s going to satisfy everyone. I see that setting mainly as a minor formatting switch to avoid writing things like 1.1E2 instead of 110; most people probably don’t want it to write out a 1000-digit number, though.

[cowtowncoder]

Just realized that a better place this is with jackson-core, since that’s where it can be more reliably caught. So recreated as:

https://github.com/FasterXML/jackson-core/issues/315