Jackson parsing readTree() does not fail for invalid json text

[ImABird001]

Jackson parses invalid text (numbers separated by space) and produces valid JsonNode. Expectation is to get an exception. I have tried few alternative ways of parsing, but so far jackson pretends the text is valid and returns first number. I discovered this by accident by validating user supplied text as json and getting true.

new JsonMapper().readTree("1 2") // produces IntNode(1)
new ObjectMapper().readTree("1 2") // produces IntNode(1)

• I dont see this issue reported, haven't found a configuration that could solve it (tried few) and experience same problem in SpringBoot Java project and separate Kotlin project with the minimum of jackson dependencies
• version 2.3.13 (latest)

[cowtowncoder]

Wrong repo; would belong under jackson-databind.

But this is intended behavior, not a bug: Jackson only reads as much content as it needs for a valid JSON Value. It does not try to consume everything there might be available, given that the white-space-separated content streams are commonly used.

Having said that, there is a way to do what you want by enabling

DeserializationFeature.FAIL_ON_TRAILING_TOKENS

on ObjectMapper (or ObjectReader) you are using. If so, mapper WILL verify no more content is available, and thrown exception if there is.

This was added in Jackson 2.9, as per:

FasterXML/jackson-databind#1583

[ImABird001]

Thx for response and suggested solution.

I was inicially creating the issue in databind, but then I thought this was a better place. My bad.

I wont pretend to understand why this is intended behavior and I understand that sometimes real world is messy and the software needs to go outside the spec to accommodate most people, but json library parsing invalid json ok by default seems like quite a misstep. Well, hopefully your suggestion will work, so that rightfully closes this issue.

I'll read through reasoning in your link and report if your solution will not work properly (which im certain it will).

[ImABird001]

The suggested fix works. Thx for quick response.

However, after reading the linked issue and couple related issues, I remain unconvinced that this is reasonable default for json library. Take that information however you will.

[cowtowncoder]

@ImABird001 I disagree with your "invalid JSON" part. Content that is read is fully valid -- it is just not the whole input.
This is not an uncommon use case, although more commonly content is a sequence of JSON values separated by linefeed.

So it is invalid for YOUR use case, fine.

Whether this should be the default behavior or not is of course matter of opinion.