Closed JooHyukKim closed 1 year ago
@JooHyukKim should we also add deserialization tests? If you feel this is too much for this PR but suspect that we do need more work on the deserialization, could you log a follow up issue?
@JooHyukKim should we also add deserialization tests? If you feel this is too much for this PR but suspect that we do need more work on the deserialization, could you log a follow up issue?
@pjfanning I certainly agree we need deserialization counterpart. And yes, let's (I will) create a follow up issue, because I think this already affects broad scope 😄
On this PR specifically, we could consider doing:
JavaType
adds detection functionality.@JooHyukKim could you create a shared method for checking the class for these Iterator.class.isAssignableFrom(cls) || Stream.class.isAssignableFrom(cls)
?
This check appears twice so it would be good to share the check (just in case we need to add more classes to the check).
@JooHyukKim could you create a shared method for checking the class for these
Iterator.class.isAssignableFrom(cls) || Stream.class.isAssignableFrom(cls)
?This check appears twice so it would be good to share the check (just in case we need to add more classes to the check).
Sure 👍🏻, Sounds great!
Come to think of it, related issues have been around a long time. Should we rebase this PR agaisnt 2.15? 🤔
Not a big deal but I wrote https://github.com/FasterXML/jackson-module-scala/pull/636 to try out this problem with Scala Iterators and there is an issue and this fix won't help (for Scala Iterators). That doesn't mean we shouldn't proceed - it just highlights that adding a JavaType based solution in the future would be useful.
To keep track of things, let's link this to FasterXML/jackson-databind#3926
resolves below issues
302
329
148