Closed amaembo closed 2 years ago
Breaking the contract of toList/Set/Map
in a single version change could cause major trouble for clients. Please provide a proper migration path:
toMutableList/Set/Map
and hint in the Javadoc of toList/Set/Map
that toMutableList/Set/Map
should be used instead. Maybe even a deprecation annotation is in order.toList/Set/Map
can be redirected to toImmutableList/Set/Map
and the Javadoc hint / deprecation annotation can be removed again.@msladek thank you for the feedback. I updated the issue description according to the current plan.
We have
StreamEx.toList()
that explicitly specified as returning a mutable collection. However, in JDK 16,Stream.toList()
method was added that is explicitly specified as returning an unmodifiable collection. So, since JDK 16,StreamEx
violates the Stream interface specification. We need to introduce a breaking change to align them:toMutableList()
method that returns a mutable listtoList()
specification.toList()
an alias totoMutableList()
by defaultstreamex.default.immutable
. When it's set to true,toList()
starts behaving liketoImmutableList()
. This way, users can test their code whether it's ready for the subsequent change.toList()
will be aliased totoImmutableList()
.The same will be done for
toSet()
. For now, let's keeptoMap()
as is, as there are too many overloads and changes there would make things even more confusing, and bloated.Also, the behavior of
toListAndThen()
andtoSetAndThen()
is not changed: the collection supplied to the lambda will still be mutable (even though it's not specified).