This was recently added in Jackson 3.0.0-rc9. #5273 The aim appears to have been to support returning collection data in a way that users couldn't modify the underlying collection data in the class instance. Unfortunately, Java Streams need to be closed and generally have a more complicated API than alternatives like having the method returning the collection data using a call like Collections.unmodifiableList to protect the collection data.
Comment From: cowtowncoder
Unfortunately, Java Streams need to be closed
Hmmh. No, typical Stream usage does not involve closing (or put differently, most Stream implementations do nothing on close()); even canonical JDK examples ignore that.
And these days with more functional APIs, often the first thing done on returned Collection is to call .stream() on it.
I agree that this is a matter of taste but I do not see value in forcing module instances to be returned as Collection instead of Stream -- caller can as easily create collection/List out of Stream if they for some reason need it, as the opposite.
Comment From: JooHyukKim
Yes, this could be matter of preference. But this could also be something that many users would come and say "why Stream/Collection? Just saying" and vice versa :-)
I recall some libraries do end up supporting both.
Comment From: cowtowncoder
@sdeleuze @yawkat @aalmiray What do you think? I can see pros and cons of Collection<JacksonModule> vs Stream<JacksonModule> and while my intuition suggests latter, I don't want to rely too much on what may be just personal preference.
And changing this is easy now but will quite soon become part of "permanent" Jackson 3.x API so if change makes sense would rather do it now. (fwtw I do not want expose both: one should be enough).
Also: while method name has already been changed (from getRegisteredModuleIds()), I suggest we should further drop "get"-prefix here (it is left, in 3.x, for "simple property accessors" and this is arguably not such a thing).