opened
cowtowncoder
username_0
So, it looks like `readTree()` methods in `ObjectMapper`, `ObjectReader` that take input OTHER than `JsonParser`, and are given "empty input" (only white-space available before end), will

* Return `NullNode` (Jackson 2.x up to and including 2.9)
* Return `null` (Jackson 2.9)

Latter behavior is what `readTree(JsonParser)` has and will do; but this accidentally changed other methods due to refactoring that unified underlying call handling (and add checking for new `DeserializationFeature.FAIL_ON_TRAILING_TOKENS`). 
Behavior for this edge case was not being tested, apparently.

Now: since behavior has been changed for all 2.9.x patch versions, I am not sure it should be changed for 2.9 branch. But it seems sub-optimal as behavior, and something to definitely change for 3.0... but probably also for 2.10.

There are multiple things we could do.

1. Change it back to 2.8, to return `NullNode`
2. Change to throw exception, as "not valid" use case
3. Change it to return `MissingNode`
4. Leave as-is, for rest of 2.x.

Although it might seem best to revert it to (1), that seems somewhat wrong, problematic, as it would now not be possible to distinguish between JSON `null` value and missing content.
And although (2) would probably make sense, if designing API from scratch, it is probably too intrusive.

So I think (3) is the best way: it avoids returning `null` or throwing Exception (both being likely to break 2.9 code), but still allows distinguishing between all possible input cases.
Change of behavior (2.8 -> 2.9) with `ObjectMappe.readTree(input)` with no content
issue
created
cowtowncoder
username_0
Note: once upon a time there was #1406, related.
comment
closed
cowtowncoder
username_0
issue