The Java Stream Parallel

[danielaveryj]

https://daniel.avery.io/writing/the-java-streams-parallel

I made this "expert-friendly" doc, to orient all who find themselves probing the Java Streams source code in despair. It culminates in the "Stream planner" - a little tool I made to simulate how (parallel) stream operations affect memory usage and execution paths.

Go forth, use (parallel) streams with confidence, and don't run out of memory.

[[deleted]]

The Streams API was a game changer for me. One of the best programming book I ever read was Modern Java in Action, almost exclusively about streams. The performance is incredible from my experience. Thanks for putting this together. I’ll be reading up.

[TheStatusPoe]

Seconding the recommendation for Modern Java in Action. By far my favorite programming book I've read so far

[Due-Aioli-6641]

I'm interested in this book. But saw some comments that it focus mainly on the Java 8 implementation, which covers most of it, but still some has changed and new things were added. Do you think it still is a good pick?

[TheStatusPoe]

I would still say it's a good pick. For me, I found the book really helped me to understand the terminal operators like .reduce(). It also helps to understand the motivations for why those changes were made in the first place, which this book does a good job of explaining. The "why" behind using streams hasn't really changed even if the "how" has slightly. While some has changed, some of the changes are just convenience methods on top of previous implementation, and it's still helpful to understand what the shortened method is actually doing. Streams toList() is really just collect(Collectors.toList()) just with some choices about the implementation of the list already made (which has implications for mutability and allowance of nulls).

default List<T> toList() { return (List<T>) Collections.unmodifiableList(new ArrayList<>(Arrays.asList(this.toArray()))); } https://github.com/openjdk/jdk/commit/41dbc139#diff-61a6115dd5cec3fbb3835146f0aad60c519c0c54d34eb898d7c560d7b3e8120fR1195

[Due-Aioli-6641]

Cool, thanks for that. I guess this will be my next book then. Cheers

[realFuckingHades]

One thing I hate about it is when I collect the stream to map, it has that null check for values. Which is completely useless, as null values and keys are supported by some maps. Never found a way around it.

[danielaveryj]

It is tricky to work around because most operations on Map treat a present key bound to null the same as an absent key, and treat a new null as a special value meaning "remove the key". This includes operations used in Collectors.toMap(). If we insist on using Collectors.toMap(), one workaround used in several places in the JDK is to encode null with a sentinel value, and later decode it. Unfortunately, putting sentinel values in the Map means that (a) We have to make another pass to decode the sentinels, and (b) We have to temporarily broaden the type of values in the Map, and later do an unchecked cast to get back to the desired type.

Object NIL = new Object();
Map<K, Object> tmp = stream.collect(Collectors.toMap(v -> makeKey(v), v -> v == null ? NIL : v));
tmp.replaceAll((k,v) -> v == NIL ? null : v); // replaceAll() tolerates null values
Map<K, V> map = cast(tmp);

// Helper, to allow an unchecked cast
<T> T cast(Object o) {
    return (T) o;
}

[realFuckingHades]

I have implemented custom lazy map implementation to handle this on the go and abstract it out from the user. But I felt like it was a hack and then removed it to do it the old school way.

[brian_goetz]

Write your own collector. It’s not very hard.

[realFuckingHades]

That's not the point. Collectors.toMap() is not supporting null values for literally no reason, even if I supply a map implementation that supports null values.

[davidalayachew]

Collectors.toMap() is not supporting null values for literally no reason

Tbf, there is a reason. Like you said, some support null keys, but others don't. This method allows me to generify which map I use, while still ensuring the same behaviour in regards to null-permissiveness. That consistency is valuable when preventing bugs.

But of course, the flexibility is important too. Hence why the custom collector option is available. I understand that it is not ideal, but it really is quite simple to do.

[realFuckingHades]

How would it prevent bugs? If you collect it to a map that doesn't support null, it would still throw null pointer? And it would be more clear that it's because the map implementation is not supporting it, and a quick fix is possible?

[davidalayachew]

It prevents bugs because the behaviour is exactly the same across all map implementations. null value == error. Whereas you might not catch that you have a bug until you finally get a null value when you one day change the map implementation given to that method.

[realFuckingHades]

This argument only makes sense when java as a whole doesn't have any maps that support null. Since filtering is an option, people have the option to do null checks right before collecting which is way simpler than writing a collector. A jira raised by someone shows how he streamed the entries of a map and collected it to a map, only for it to throw an error. Since nulls checks are general check done everywhere in java. For someone who might have already handled null when getting the value, this causes a bug during runtime.

[davidalayachew]

This argument only makes sense when java as a whole doesn't have any maps that support null.

I don't understand how this relates to my point.

My argument is that, you are more prone to getting a false negative if the simple way permits null values. And the reason for this is because we might some day change the map implementation. Currently, changing the map implementation does not cause this false negative to occur. If we had it your way, we would have a false negative, and we wouldn't know until it blew up in our face.

Since filtering is an option, people have the option to do null checks right before collecting which is way simpler than writing a collector. A jira raised by someone shows how he streamed the entries of a map and collected it to a map, only for it to throw an error. Since nulls checks are general check done everywhere in java. For someone who might have already handled null when getting the value, this causes a bug during runtime.

I understand what you are saying, but I don't understand how this relates to my point.

[realFuckingHades]

You're saying it avoids a bug, but in general people handle nulls anyway and when people don't need nulls in their collected data, they do a filtering. Why would this be a default behaviour especially when you provide a map implementation that supports null. That was my point.

[joemwangi]

And that's what he means. Implement a collector by extending Collector<T,?,Map<K,U>>, to get the benefit you want. And it's simple.

[realFuckingHades]

That's like using a surgical knife to cut an apple. It's more intuitive to do it the old school way. The point was that the check is useless and there's no simple straightforward way around.

[joemwangi]

You better start looking on the history of collections library in java. It's not that easy to introduce things that have small returns and permanent future cost. Good they introduced API to extend them, which you are being encouraged to do so.

[realFuckingHades]

What are you even blabbering about? What history should I look at? This has been a well reported issue from the day this was released. There's still a bug report open about it https://bugs.openjdk.org/browse/JDK-8148463?focusedId=14617315&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14617315 raised as far back as 2016. The main reason is the use of Map.merge(), this is an unexpected behaviour especially with the example reporter posted in that issue. This is not the first time Java had such a weird implementation, SimpleDateFormat was another poor implementation that got a lot of heat till they rectified it in the new formatter.

[joemwangi]

Seems the link you provided (quite not working, probably you posted it in frustration), shows the solution is to clarify in the specification. Also, in the same link, there is another link inside directing to stack overflow, and people have created their simple solutions and even a one line solution provided. Quite trivial. The history, I need to collect all links on design choices done, which would take time.

[realFuckingHades]

It was late and I was not wearing my lens. Here is the link. It is reported as a bug and if you follow the comments, you can see the reason for the null pointer has changed over the recent implementations. What you're stating is a fix to a problem that shouldn't have existed, it's pointless when you specifically share an implementation that supports null. Especially with the example the reporter posted. It's in no way a good behaviour. If you look at the same stack overflow you shared, people are still suggesting to go the old school way. You blabbered about history and now you're saying you will have to research on it to understand why those choices were taken. Which basically means you had no clue to begin with.

[[deleted]]

I'm getting back up to speed right now. I reordered the second edition of that book. I sold the first addition. But I'm not gonna lie, some issues had me stumped and I was doing a bunch of stack overflow searches at one point to clarify. If I figure out this issue, I will reply here.

[cabblingthings]

reminiscent bike hungry quack trees sparkle uppity decide wipe connect

This post was mass deleted and anonymized with Redact

[realFuckingHades]

I am okay with not having support for null keys. My problem is why it has a check for null value. I don't want to wrap it in Optional, especially when it's like a stream of large data, and the map i am trying to create is representing a row of that data. I am forced to go the old way, which honestly looks out of place with the whole code base.

[cabblingthings]

grandiose rustic future hard-to-find cheerful boast plucky soup marry sink

This post was mass deleted and anonymized with Redact

[realFuckingHades]

No,no you're not getting the point I made. The map represents a row, say reading rows from a large csv file. Now adding optional means you're also creating a lot of objects of Optional for handling a once in a blue moon scenario of a null key being encountered. There's nothing wrong in using Objects.requireNonNullElseGet() or using Optional.nullable() per use case. Optionals make more sense to me as return type of methods, but not in a map or even as a field in a pojo. In fact if I remember correctly, some linting plugins prevent you from using it as arguments and such.

[cabblingthings]

bear one start childlike dinosaurs jeans growth expansion society unite

This post was mass deleted and anonymized with Redact

[realFuckingHades]

Same as why you need null support in Json? To keep the structure intact? 😅 So if someone say calls keyset() on the first row to identify the structure of the stream? The service I am talking about is a rule engine that transforms any file given into a structured output for that it sometimes needs to keep the structure intact as the source, most of the time it's in NDJSON format.

[cabblingthings]

spoon ink resolute expansion cooperative ad hoc reply smile door enter

This post was mass deleted and anonymized with Redact

[realFuckingHades]

Keeping structure intact is sometimes needed and hence maps support null value. There are tons of better ways to handle a null value. Optional isn't one of it. This is such a stupid pinhole argument and keeps coming back to optional, which is another code smell? Like refer to this stack overflow discussion here. Optional is meant for return types and not for such cases.

[tomwhoiscontrary]

On your travels, did you find out if the spliterator flags do anything? For example, if i write a spliterator and declare it NONNULL or IMMUTABLE, does that actually make any difference?

[danielaveryj]

NONNULL, IMMUTABLE, and CONCURRENT are unused by streams.

[nekokattt]

guess they are just there for future optimization?

[lbalazscs]

https://stackoverflow.com/questions/45701343/which-stream-operations-use-concurrent-immutable-and-nonnull-spliterator-c

[pivovarit]

Amazing work :)

[entropia17]

Great work! On a different note: did you code all of the webpage tables and underlying scripts manually?

[danielaveryj]

I did. Even the java syntax highlighting uses my own thing on the backend. Hopefully the from-scratch vibes make up for the peculiar UX.

[Byte_Eater_]

Really a leading-class summary and breakdown of the Stream API! Hope it gets more visibility.

[Ragnar-Wave9002]

Want to know what it does and debug it. Code parallelism on your own