JDK-8260680 : PipedOutputStream.write in a JShell throws error "pipe closed"
  • Type: Bug
  • Component: tools
  • Sub-Component: jshell
  • Affected Version: 11.0.9
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2021-01-30
  • Updated: 2021-09-30
  • Resolved: 2021-06-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
Related Reports
Duplicate :  
Relates :  
The reproducer starts two threads, 1 for initialising Input/OutputStreams, the second which sets up a JavaShellToolBuilder which accepts these Streams as parameters.

The reason for "Pipe closed" is as follows:

This issue is seen when upgrading from jdk11.0.8 to jdk11.0.9. A major JLine upgrade went into this version (3.9.0) (https://bugs.openjdk.java.net/browse/JDK-8246176)

The bug seems to have been introduced in this upgraded source code, more specifically in the LineReaderImpl::readLine

Here is a snippet from lines 637-640:

	Binding o = readBinding(getKeys(), local);
	if (o == null) {
		throw new EndOfFileException();

It appears when the program runs, this EndOfFileException is always thrown. When going deeper into the readBinding method, there is the BindingReader::readBinding method which makes a call to readCharacter(). This appears to always return a -1 (EOF) in the case of this reproducer and throws the Exception.

The reason this has not been caught earlier is because of https://bugs.openjdk.java.net/browse/JDK-8215438 “CTRL+D causes EOF”

 While this fix does indeed stop the CTRL+D error, by catching this error silently, it is allowing the JShell to exit quietly when an EOF is incorrectly caused by something else.

Flagging as jdk11u-na. Duplicate issue was backported to 11.

As described by Jan, that backport did indeed resolve the issue. Closing this as a duplicate

There is JDK-8247403, which tackles a related issue. With this issue in mind, JDK-8247403 introduces an API, so (if it passes), it should cover the usecase mentioned here as well. Due to the API, it won't be directly suitable for a backport, but if the API is removed, the rest of the patch should be backportable, and the idea is that the backport should solve this issue.