Skip to content

Conversation

JooHyukKim
Copy link
Member

... as per #5287

@sdeleuze
Copy link

sdeleuze commented Sep 1, 2025

Probably worth refining the Javadoc of JsonNode.stringValue() and JsonNode.stringValueOpt() to replace "JSON String" by "JSON string or null" or something along those lines.

assertEquals(null, node.stringValue());

// But also check defaulting
assertEquals("foo", node.stringValue("foo"));
Copy link
Member

@cowtowncoder cowtowncoder Sep 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No: should return null, now that it is legitimate String value.

Copy link

@sdeleuze sdeleuze Sep 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I am stongly in favor of keeping the PR as it was since null typically express the absence of value. I think the least surprising behavior is the previous PR implementation, with node.stringValue("foo") returning "foo" and node.stringValueOpt().isPresent() returning false when the string is null. Both should work consistently as a default value is supposed to be returned in the absence of value.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm okay I am a bit confused now.
Seems like we missed talking what each case should handle defaultValue.

Which one should be?

  1. assertEquals("foo", nullNode.stringValue("foo"));
  2. assertEquals(null, nullNode.stringValue("foo"));

Let's continue discussion on #5287

Copy link
Member

@cowtowncoder cowtowncoder Sep 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmh. I guess I changed my mind -- will revert to earlier state. This mostly thanks to Optional limitation.

@cowtowncoder
Copy link
Member

@sdeleuze @JooHyukKim Changed as discussed. Still looking forward to suggestions for better Javadocs but ready to approve if we agree on behavioral change.

@sdeleuze
Copy link

sdeleuze commented Sep 5, 2025

LGTM

@JooHyukKim
Copy link
Member Author

LGTM as well.
JavaDoc seems good for now.

@cowtowncoder cowtowncoder merged commit 0f2847a into FasterXML:3.x Sep 5, 2025
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants