Numbers without decimal numbers are now treated as Double instead of Integers

[busches]

Describe the bug When an number is returned in a json response with no decimal, I'd expect it to be of type Integer, not type Double.

To Reproduce Steps to reproduce the behavior:

I'm upgrading from the following:

testImplementation("com.konghq:unirest-java:2.3.11")
testImplementation("com.konghq:unirest-objectmapper-jackson:2.3.11")

To:

testImplementation("com.konghq:unirest-java:3.11.06")
testImplementation("com.konghq:unirest-objectmapper-jackson:3.11.06")

I have a json response that returns the following:

{ "integer": 3 }

I'm getting the data like so: Unirest.get("localhost/getInteger").asJson().bodyobject.toMap()["integer"]

Expected behavior In version 2 that comes over as a type of Integer, now it's coming back as a Double and failing my tests, as assertEquals(3, 3.0) is not true.

Environmental Data:

openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)

Additional context I'm using this inside of a Kotlin application.

[ryber]

We switched from org.json to gson as the underlying json implementation and this is gson's intentional behavior when you don't specify what you want (like when you to .toMap()). Apparently this is by design to match the behavior of JavaScript (https://github.com/google/gson/issues/692)

If you want it to be a int, you would have to ask for an int like

Integer i = Unirest.get("localhost/getInteger")
                .asJson()
                .getBody()
                .getObject()
                .getInt("integer");

There is likely a way to change this but it would involve overriding the internal mappers of GSON which I think would be a mistake especially when in most cases the system will give you what you want as long as you tell it what you expect.

[ryber]

hrm I could look at pulling this change in, given we have a prescience for ints https://github.com/zenglian/gson/commit/9b7c66d55adf8147c039f90cc4ada93ba494c225

[busches]

Good to know on the background. I didn't see it specifically called out in the notes and wanted to bring awareness to the issue to see if it was intentional. As you mentioned, we do have workarounds, but it does require more code/effort than we were using before. :)

[ryber]

It wasn't intentional. I'll look at getting in a patch to fix it. I noticed Google has like 20 different very angry issues about it I get that they wouldn't at this point want to break backwards compatibility. Luckily our backwards is more sane 😀

[ryber]

@busches can you try 3.11.07?

[busches]

@ryber confirmed back to the original behavior, thanks!