These classes are very old, their semantics are ill-defined, and they have many implementation quirks and bugs that are visible to applications.

Instead of being a "plain" pipe that contains a buffer of bytes and two ends with open/closed states, the Piped* classes also attempt to keep track of which threads are using them. This interacts with their state in unusual ways. A pipe can be "broken" even if both ends are still open. An evaluation by Mark Reinhold in JDK-4028322 (almost 22 years ago) said:

    That PipedInputStream tries to keep track of its reader
    and writer threads seems to me to be misguided.

Recently, some RFEs have come in that requested enhancements, including a new method to "break" a pipe, and better documentation.

Instead of trying to fix up, document strange behavior, and enhance these mechanisms, they should be deprecated instead. Deprecation will allow us to close some other outstanding bugs and RFEs. We should also recommend alternative mechanisms. For example, to communicate objects between threads in the same JVM, a concurrent data structure (e.g., ArrayBlockingQueue) should be used. If it's truly necessary to transmit bytes between threads in the same JVM, java.nio.channels.Pipe can be used.