Jackson 3 TypeFactory CollectionTypes

[pjfanning]

Could we consider fixing the issue described in

jackson-databind/src/main/java/tools/jackson/databind/type/TypeFactory.java

Lines 1423 to 1426 in 50b74b4

	// 01-Nov-2015, tatu: As of 2.7, couple of potential `CollectionLikeType`s (like
	// `Iterable`, `Iterator`), and `MapLikeType`s (`Map.Entry`) are not automatically
	// detected, related to difficulties in propagating type upwards (Iterable, for
	// example, is a weak, tag-on type). They may be detectable in future.

about not treating some collection types as collection types in TypeFactory.

• Stream
• Iterator
• Map.Entry

[JooHyukKim]

+1. Would help in cases like this PR in FasterXML/jackson-dataformat-xml#597

Only crossing out because this issue is against Jackson 3 not affecting the linked PR. But still +1 👍🏻 😄

[pjfanning]

+1. Would help in cases like this PR in FasterXML/jackson-dataformat-xml#597

I meant to say Jackson 3 in the issue title. I don't think there will be an appetite to change this in Jackson 2.

[cowtowncoder]

Before considering those possibilities (note: they cannot be CollectionTypes as types do not implement Collection), it'd be good to know what the intended benefit is -- is it just for more convenient detection of type parameters or something else? Not against improvements, just want to know the goal.

[yihtserns]

...they cannot be CollectionTypes as types do not implement Collection...

Looking at the quoted code, I think he meant to say "collection-like types" not "collection types".

[cowtowncoder]

@yihtserns Right, that makes sense. But I think I'd prefer new "IteratorType" (or "IterableType"), since these are not (depending on one's POV, one can disagree) Collection-like -- difference between value and sort of pointer to value.
Part of the challenge is that I think there's a chance (maybe small) that some existing code might otherwise assume properties for newly discovered types that are not true.

[cowtowncoder]

One quick note on Map.Entry: that sort of qualifies as MapLikeType. But here I am particularly worried about compatibility: registering Serializers/Deserializers via Serializers / Deserializers has separate callback methods -- so changing JavaType for Map.Entry would likely break some registrations.

Same is actually true for possible new "IterationType" (or whatever name we'd use).
For 2.x we'd need to consider whether to change Serializers/Deserializers by adding new method, or not.

[cowtowncoder]

Name suggestion: IterationType.

[cowtowncoder]

... and now that I finally read my own code comment, I realized that Old Me pointed out relevant challenge wrt add-on/tag types. So there may be reasons why there may be challenges in detecting various iterator types. But maybe it's worth trying things out and see what happens.

[cowtowncoder]

Ok: realized another quick thing:

1. Separate type makes sense for actual iterators (Iterator, Stream) but
2. Does NOT make sense for Iterable -- that's not iterator, it's something that can produce iterator. And as such is almost certainly Collection- or Map-Like type

With that, I think progress can be made.

This still leaves the question of Map.Entry -- I think it could be upgraded into MapLikeType, but maybe as separate PR/issue

[cowtowncoder]

So, support for IterationType (which initially covers Iterator, Stream, DoubleStream/IntStream/LongStream) has been added for 2.16. This may perhaps be closed.

Not sure about Map.Entry, could consider making it MapLikeType; if so, should file separate issue.