Change `JsonNode.with(String)` and `withArray(String)` to consider argument as `JsonPointer` if valid expression

[cowtowncoder]

With #1980 there are new methods/overloads for withArray() and with(), which take JsonPointer.
The old methods that take String should be retrofitted in 2.x so that:

1. If argument is valid JsonPointer (that is, starts with leading '/` or is empty String ""), it should be used as such
2. Only if argument is not a valid JsonPointer, should it check existing property.

For Jackson 3.0 we can just drop the check and expect valid JsonPointer String representation.

The reason for change is to make expected main use case work, while retaining reasonable backwards-compatibility.

[dan2097]

The reason for change is to make expected main use case work, while retaining reasonable backwards-compatibility.

For the corner case where a user is creating/fetching keys that start with a forward slash this change is unequivocally not backwards compatible. Given that with was deprecated as part of #3535 did its behaviour really need to change...

(I'm not personally effected by this change, was just wondering what the closest replacement for the deprecated with() method was as the Javadoc didn't provide a suggestion, and was surprised to see the JsonPointer parsing logic. As far as I can see there isn't an exact replacement if you want your input interpreted as a literal key. For my use case putObject was actually appropriate)

[alasdairhurst]

The reason for change is to make expected main use case work, while retaining reasonable backwards-compatibility.

For the corner case where a user is creating/fetching keys that start with a forward slash this change is unequivocally not backwards compatible. Given that with was deprecated as part of #3535 did its behaviour really need to change...

(I'm not personally effected by this change, was just wondering what the closest replacement for the deprecated with() method was as the Javadoc didn't provide a suggestion, and was surprised to see the JsonPointer parsing logic. As far as I can see there isn't an exact replacement if you want your input interpreted as a literal key. For my use case putObject was actually appropriate)

We hit this exact issue when upgrading Jackson. The main issue is around looking up or performing iterative logic on keys dynamically rather than hardcoding the pointer or parameter argument. This leads to an unexpected difference in behavior when the key just happens to start with a slash. (I.e. when traversing JSON data that involves HTTP path segments, for example OpenAPI specs).

In our case, without a workaround exposed on the JsonNode class, we had to manually escape any dynamic property passed into with or withArray that started with a / and turn it into a valid json pointer for that property with escaped special chars for it then to be compiled and executed later which does impact performance in sensitive environments.

// previous
obj.with(key)

// current
public static String property(String property) {
    // Bypass JsonPointer encoding/decoding/compiling by returning the original prop where possible
    if (!property.startsWith("/")) {
	return property;
    }
    // Can't be used as a basic prop lookup so encode as JsonPointer 
    return JsonPointer.valueOf("").appendProperty(property).toString();
}

obj.with(property(key))

@cowtowncoder Could we ensure this one is added to the "Changes, compatibility" section of the 2.14 release notes indicating the breaking change please?

[cowtowncoder]

@alasdairhurst Happy to add a note -- could use help in formulating what is said.
But can start by adding a link.

[cowtowncoder]

Added link, brief description.

For anyone looking into solution, Jackson 2.16 added JsonNode.withObjectProperty(String) that will NOT try to auto-detect JsonPointer expression but use String as the property name, escape as necessary.
See #4095 for details.