Tatu Saloranta

@kilink One possibility: postpone Guava baseline upgrade to Jackson 2.19, merge this in after 2.18.0 released? This gives us more time.

Would like to proceed with this, wrt merging into 2.19, but need 2 things: 1. PR needs to re-based (or re-created against `2.19`) 2. CLA with that, I'd be happy...

Now that #158 complete, baseline not a blocker. But looks like this pr is not mergeable as-is...

On second thought... while access in general should not require synchronized, it looks like there might be one big wrinkle -- resolution of cyclic dependencies. Looking at this: ``` public...

Not safe to remove, closing.

Sounds like a bug indeed. /cc @here-abarany

Ideally would be fixed in 2.18 branch if safe enough (that's our first Long-Term Support branch for backporting).

Added test com.fasterxml.jackson.dataformat.cbor.tofix.StringRef599Test Test added in 2.19 branch (alas, 2.18 uses old JUnit4 and has no `@JacksonTestFailureExpected`) -- fix itself can be backported, I hope.

@here-abarany `CBORParser` will still iterate over tokens, regardless. But there may be some optimization for case of "nextToken()" called without accessing String value of preceding `JsonToken.VALUE_STRING`.

Fixed via #627 in 2.21(.0) and 3.0.2 (both to be released). May backport in 2.18 if feasible.