Add `JsonNode.optional(String name)` and `JsonNode.optional(int index)` to be able to get an Optional `JsonNode`

[burdoto]

NOTE: considered part of JSTEP-3

---

So I had this idea of how nice it would be to have a getter method that returns an optional JsonNode, like #path(String name) does, but when returning an Optional, it would be simpler to only use a node when its actually present, or handle cases that its not present in.

Current Solution:

this.guild = data.has("guild_id") ? discord.getServer(data.get("guild_id").asLong()) : null;

With optional nodes:

this.guild = data.getOptional("guild_id").map(node -> discord.getServer(node.asLong())).orElse(null);

In this scenario, the difference is counter intuitive, because I can use a ternary-if in this case.
See this scenario:
Without the addition:

        long afkChannelId = data.path("afk_channel_id").asLong(-1);
        if (afkChannel == null || afkChannel.getId() != afkChannelId) {
            afkChannel = afkChannelId == -1 ? null : discord.getChannelCache()
                    .getOrRequest(afkChannelId, afkChannelId);
            traits.add(AFK_CHANNEL);
        }

With the addition:

        Optional<JsonNode> node = data.getOptional("afk_channel_id");
        if (afkChannel == null || node.map(idN -> idN.asLong() == afkChannel.getId()).orElse(false)) {
            afkChannel = node.map(json -> discord.getChannelCache().getOrRequest(json.asLong(), json.asLong())).orElse(null);
        }

I think this scenario could show why the addition could be helpful.
If this idea gets approved and it is wished for; I could work on a PR myself.

[cowtowncoder]

You may not be familiar with MissingNode, which serves purpose similar to Optional.
It is produce by various calls like:

JsonNode maybeValue = objectNode.path("tree").path("branch");
JsonNode otherMaybe = objectNode.at("/tree/branch/value/3");

in cases where there is no matching node.

You can call usual methods on MissingNode (which coerces to default values), or check for "missing"ness (node.isMissingNode()).

So. Although I am not totally opposed to some level of compatibility with JDK Optional for Jackson 3.0 (2.x it can not be done as that's Java 8 feature), I want to make sure there is real need.

[burdoto]

I am already aware of the missingnode technique, I just feel that my optional-variant is missing.
What if you're trying to get an optional int node, and set it to null if it's not there?
You can't pass null to the #asInt(int) method, as primitives cannot be really "null" in that kind of sense
yet you might want to have it be null if it's unavailable.
With the optional variant you could do node.optionalInt("uses").orElse(null)
Where with the current version, the smallest solution to this is to use a ternary with node.has("uses"),which also means you have to either store the node of "uses" or access it at least twice

[burdoto]

Parallel to that, what about a method asIntOrNull() that either gets the actual value of the node or null?

In that case, we would lose the option of using the Optional#map method, though, which would be a huge advantage to have

[cowtowncoder]

I don't think I want asIntOrNull() since that opens doors to combinatorial explosion (for different types).
Back to optional: there are asInt(defaultValue) and similar variants that should cover use cases.

But perhaps adding simple optional(key) and optional(index) would make sense for inter-operability: there are many Java APIs (streaming most notably) that would benefit, and adding that would be trivial.

[JooHyukKim]

Lemme start this one if no one has started?
Seems like a good start for picking up JSTEP-3

Wrt implementation details, would be one PR seems okay? Including following tasks

• Add JsonNode.optional(String name) and JsonNode.optional(int index)
• Add appropriate implementations in subclasses
• Write optional() tests in the one isolated class. We may try find default-test-class for each JsonNode-subclasses but idk.

[cowtowncoder]

Sounds good. The only (?) open question -- which I should have noted here -- is the naming.
While optional() is a reasonable possibility, I think there are 2 possible alternatives to consider:

• opt() -- shorter, if that matters, comparable to get() and path() (which this new method is similar to)
• getOpt() -- same length, but would be grouped next to get() in Javadocs (and IDE auto-completion), which might be desireable.

WDYT @JooHyukKim, @pjfanning, @yawkat ?

[JooHyukKim]

Hmmm I was actually 50/50 on 'getOptional()' vs 'optional()'. Atm I am more concerned about users complaining about lack of intuitiveness ("what does opt mean?") rather than method name being too long. But I'm open to other suggestions as well.

But with the current PR I chose to follow the title.