JsonDataSource fails with large integer value

Aspose.Words Product Family
,
1

When using a JSON object with a large integer value, the application throws an error indicating that the integer is too large for an Int64 . How can I modify the code to handle large integers in JSON without encountering this error?

Error message:

java.lang.IllegalStateException: There is an error on reading the JSON. JSON integer 100000000000000000000 is too large or small for an Int64. Path 'invalidNumber', line 1, position 38.

Here is a snippet of the code where the error occurs:

String invalidJsonString = "{\"invalidNumber\":100000000000000000000}";

ByteArrayInputStream dsByteStream = new ByteArrayInputStream(
    invalidJsonString.getBytes(StandardCharsets.UTF_8));

JsonDataLoadOptions options = new JsonDataLoadOptions();
options.setSimpleValueParseMode(JsonSimpleValueParseMode.STRICT);

JsonDataSource dataSource = new JsonDataSource(dsByteStream, options);

I am using aspose-words version 24.1.

Thanks in advance.

2

@e12893 The exception is expected wince the integer value is too large. The maximum allowed value in int64 is 9223372036854775807. Probably we can read the value that cannot be parsed to int64 as string to prevent the exception. Is this acceptable for you?

We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): WORDSNET-27584

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

3

Thanks for your quick response!

Would it be possible to handle numeric values larger than Int64 (or long) as a BigInteger (or BigDouble)?

4

@e12893 Thank you for your suggestion. I added it to the created issue.

5

@e12893

We have completed analysis of WORDSNET-27584 and here is the result. This is expected behavior rather than a bug.

We cannot use different types for integer values based on a range where a particular value falls within. The reason is that using of different types for integer values would require using of different templates for values of these different types.

For example, a template expects an integer value and then adds it to another integer value. If we used a string for the first integer value (because it is out of the range) then the sum would not be an expected value (a concatenated string).

Using of BigInteger may seem not so big deal, but interfaces and built-in abilities of BigInteger and regular integer types are very different, for example, there is no native support for operators involving BigInteger, which would be expected by users when dealing with integers. So, once again, different templates to handle BigInteger and regualar integer values would be necessary.

However, there are a few workarounds we can suggest:

  1. Use double values in JSON instead as follows:
{"invalidNumber":100000000000000000000.0}

Then, in a template, you can use a format to skip a fraction like this:

<<[invalidNumber]:"#">>
  1. Use string values in JSON and initialize BigInteger values explicitly in a template upon them:
{"invalidNumber":"100000000000000000000"}

Before building a report, make ReportingEngine be aware of BigInteger in a template this way:

ReportingEngine engine = new ReportingEngine();
engine.getKnownTypes().add(BigInteger.class);
...

Then, in a template, a BigInteger value can be initialized explicitly like so:

<<[new BigInteger(invalidNumber)]>>
6

@ivan.lyagin

Thanks for looking into this further.

I don’t think any of the provided approaches will work for me since they require an update to every template that references a numeric value.

I ended up converting numeric values that do not fit into the int64/float range limits to the min or max value allowed (i.e. 9223372036854775807, -9223372036854775808, etc) before passing it to JsonDataSource.

7

@e12893 It is perfect that you managed to resolve the problem on your side. Please feel free to ask in case of any further issues, we are always glad to help you.

8

@alexey.noskov

Thanks.

On a similar note, I noticed that although JsonDataSource supports very small floating-point numbers, like 1.17549435e-38, when adding this property to my template it displays as 0.0.

Is there a precision limitation being applied here? If so, what is the limit for floating-point numbers?

9

@e12893 We will check and get back to you soon.

10

@e12893
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): WORDSJAVA-3005

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

11

@alexey.noskov I see that the ticket is closed. Was there a limit that was specified?

12

@e12893,

We did not set any additional restrictions, leaving the limits as for the double type.

13

The issues you have found earlier (filed as WORDSJAVA-3005) have been fixed in this Aspose.Words for Java 24.12 update.