I recently posted about some issues I've been having with hanging reads when using NIO pipes. After looking into it further, I think I may have run into a known bug in the JDK, specifically related to Windows. The bug report indicates it's unresolved, but there's a related subtask suggesting a workaround was included in JDK 17 as of version 17.0.5 where the Pipe implementation should use TCP sockets instead of Unix sockets. However, I've checked my Amazon Coretto 17.0.10 setup and it seems to still use Unix sockets. I'm looking for some clarification on a couple of points:
1. Is this really an issue with the JDK/Windows or could it be something wrong with my own code?
2. Has the JDK reverted to using Unix pipes in versions after 17.0.5?
2 Answers
Honestly, I’ve never really understood the purpose of the NIO Pipe class. If you're just passing data within the same Java program, there are plenty of classes in the java.util.concurrent package that could do that more efficiently. Using OS pipes seems like extra overhead to me. In my own projects, I created custom classes to handle data transfer without falling into the pitfalls of TCP socket management, though they’re mainly for testing purposes.
Not every fix from Oracle is backported to the JDK updates, which I've seen throughout different Java versions. You might want to try Java 21 to see if that resolves the hanging issue. Just a thought!
That's true, but I noticed there’s a task aimed at backporting fixes to 17 that's marked as fixed. I can't upgrade to 21 for this project, but I’ll definitely check how other JDK versions perform with this issue in a few days.
I see your point. I could switch from Pipe to a buffer queue, but I like maintaining a consistent method for handling data throughout my workflow. Switching to a local SocketChannel could work too. Regarding a pure Java implementation, it seems like the NIO pipes might leverage direct buffers to avoid heap copying, which can be beneficial for performance in certain scenarios.