Well, there is no public mutable BigDecimal
companion class, so there is no Collector
using it. But you should not worry about the performance implication of the instance creation unless a profiling tool tells you that there is a problem.
Modern JVMs like HotSpot are usually good at dealing with temporary objects created in a hot loop. Even if they are not able to elide the allocation, the allocation costs are not so big. This is different to, e.g. String::concat
where the instance creation costs do not only include the allocation, but copying the entire contents of the previously created String
instances, yielding a quadratic time complexity of such reduction (unless the optimizer manages to rewrite such code). The same would apply to attempts to produce a Collection
via pure (immutable) reduction.
This might be contradicting to the existence of primitive type specializations like IntStream
, LongStream
and DoubleStream
, but that’s a trade-off. Generally, the preference of the JRE developers is towards improving the JVM performance (for the benefit of all value types) rather than adding a mutable helper class for every immutable class. There might be a continuity of special support for primitive types until the arrival of full value type support, but don’t expect the addition of new public mutable companion classes for immutable types (unless we’re talking about construction costs like in the String
example).