document that the new buffer recycler support may cause issues if used with non-Jackson dataformats

[pjfanning]

It is my understanding that IOContexts only really need to be closed if a user has enabled a non-default BufferRecyclerPool.

Hopefully, we will be able to fix up all the Fasterxml Jackson parsers and generators to close IOContexts but that work is not yet done (beyond the parsers and generators fully implemented in jackson-core).

There are also parsers and generators that are part of the Jackson ecosystem but that are not maintained by the FasterXML org. These are more likely not to know about or to have had time to update their code to close IOContexts.

There are a number of non-FasterXML projects listed on https://github.com/FasterXML/jackson

We should add warnings to the Jackson 2.16 release notes and to the Javadoc of the new methods to adjust the TokenStreamFactory(eg JsonFactory) buffer recycler pools.

wdyt? @cowtowncoder @mariofusco

[cowtowncoder]

Yes, I think this would belong to under "Compatibility" section of https://github.com/FasterXML/jackson repo's Wiki entry for Release 2.16.

[mariofusco]

This is correct but anyway we need to gradually guarantee that all parsers and generators, together with their underlying IOContext, are correctly closed regardless of the underlying pool in use.

[cowtowncoder]

Right, that needs to happen and tests would be great. But there is also the backwards-compatibility aspect so that although we do not formally guarantee it, we try to have compatibility between "adjacent" versions in dependency order: specifically, it should be ok to have -- for example -- jackson-core 2.16, depended on by, say, jackson-dataformat-toml 2.15 (but NOT vice versa).

And it is for this use case where it is nice that closing of IOContext is not really required.
More a nice to have, really, since official line is that all minor versions should align (be same). And since recycling of buffers still requires appropriate call to _releaseBuffers to return to recycler, even if BufferRecycler itself is available via ThreadLocal.