`OutOfMemoryError` when writing BigDecimal

(note: moved from https://github.com/FasterXML/jackson-databind/issues/1316 reported by @gmethvin)

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]

I think a shorter limit makes sense, maybe 100 digits max, but I think the only way to make everyone happy is to have minimum and maximum scale settings or something like that.

Let’s say we set the limit to 9999 as you suggest. That means each number can occupy a maximum of (slightly less than) 10KB of space. If I had an array with a lot of these I could still easily see it causing a similar error.

I suspect most users of the WRITE_BIGDECIMAL_AS_PLAIN feature are just being anal-retentive about how numbers with smaller exponents look, e.g. .0012 might look better to them than 1.2E-3 and 12 better than 1.2E1. But they generally don’t want to see 1 followed by 30 zeroes instead of the much more compact 1E30.

Actually, I can’t think of any other valid reason to use that setting other than making numbers more human-readable. (If your app requires JSON numbers to be formatted a particular way to actually function, then it’s not using JSON properly.)

[cowtowncoder]

At this point I think we are all set, from my point, and see no reason to make further changes.