It all failed when .stream() appeared. Why make people use .stream() for functional programming, plus streams aren’t even reusable, I almost wish they invented a new operator based on an exotic UTF-8 character than those 9 extra characters. Fonts should have a ligature for .stream().
And now let’s talk about .collect(toList())…
And records which look like ugly beans…
Java is the land of the verbose. But it can probably be solved with 9 extra characters on every line.
Re:Java 25 Officially Released
by never_inline on Wednesday September 17, 2025 @07:17AM
(#45274352)
It's very difficult for a language designer to satisify the aesthetes.
starting with JDK 16, Stream has .toList() that will save you ten characters for the .collect()
Nobody complains about the Rust turbo-fish operator which is pretty verbose too. Java has already has introduced a direct toList()/toArray() anyways.
let v = (1..5).collect::<Vec<i32>>(); // Cool RustStreams should be built in collections, not a .stream().map(…).toList() convolution. In know its incompatible with weird frameworks who already overloaded the .map() method, but well… let them recompile.
That was in 2008, we’d be happy by now; and Java had no qualms asking everyone to change the package names from javax’ to jakartax’ in Java 21, so they should have issued a java.collections package and deprecated the lists i java.utils.
If v’s type can be inferred, you don’t need to give that extra hint to the type checker, likewise for 1..5. And Java Streams’ toList produces an immutable list.
Re:Java 25 Officially Released
by redditor98654 on Friday September 19, 2025 @07:36AM
(#45300435)
One benefit is that it makes these operations lazy. There are no intermediate lists created when you call a map on a stream. If map were a method in a list, it would need to return a new list. And if you have multiple such maps etc, it would create more such lists for each map invocation.
It's an uphill battle, but it might just climb the hill because it's still such a behemoth.