Change `JsonNode.stringValue()` of `NullNode` to return `null`, not fail (3.0)

[cowtowncoder]

(note: follow-up to #5283)

Initial implementation of "Extended set of scalar value accessors " of JSTEP-3 contains implementation of

JsonNode.stringValue()

(and 2 variants, stringValue(String defaultValue), stringValueOpt())

that will NOT accept JSON null as legitimate value, and then throws exception (or returns "defaultValue()"
But based on developer feedback, it seems sensible to consider JSON null as indicating value to return as Java null (in case of stringValue()).

NOTE: JSON null will lead to returning "default value" for stringValue(defaultValue) and Optional.empty() for stringValueOpt().

[cowtowncoder]

One open question: should MissingNode be considered null-equivalent for stringValue()?
I am thinking not, but asking just in case others disagree (WDYT @sdeleuze )

[sdeleuze]

I agree it should not.

[sdeleuze]

But as mentioned here, I disagree that node.stringValue("foo") should return null for null nodes. null should consistently mean "absence of value" for both stringValue(String defaultValue) and stringValueOpt(). Both should have @NonNull return values and handle null in a consistent way.

[cowtowncoder]

But null does not mean absence of value -- MissingNode does?

opt variants must return "empty" since there's no "explicit null" for Optional.

I am confused.

[sdeleuze]

null in Java does mean an absence of value (represented by NullNode in Jackson), while MissingNode does mean absence of node, they are different types in Jackson and we should not mix both concepts IMO, even if when there is no node, there is indeed no value.

In case of the presence of node but absence of value (NullNode) :

• stringValue() returns null
• stringValueOpt() returns empty
• stringValue(String defaultValue) should return the default value (since there is absence of value, we want a default one, with the return type always non null)

IMO there should be consistency between stringValueOpt().orElse("foo") and stringValue("foo") otherwise that's very confusing.

[cowtowncoder]

I am bit concerned about specific use case of explicit JSON null being used as override for non-null JSON values -- but cannot really argue it translating to specific behavior here.

So let's go with what @sdeleuze said.

[cowtowncoder]

Merged, will be in 3.0.0-rc9.