TextFromStandardInputStream seems not to work well with JLine #35
Milestone
Comments
|
I have a look at this. |
stefanbirkner
added a commit
that referenced
this issue
Dec 7, 2015
`System.in.read()` blocks until it faces the EOL character(s). This cannot be easily emulatet because that behaviour is implemented in native code. The first attempt was sending -1 after the end of each text or line. This is an insufficient solution because -1 indicates the end of the stream. It seems that the blocking behaviour is mainly needed for code that uses Scanner (which uses `System.in.read(byte[], int, int)` internally.) Hence the -1 hack was replaced by an enhanced implementation of `read(byte[], int, int)` that returns the whole next line. Fixes #35.
stefanbirkner
added a commit
that referenced
this issue
Dec 7, 2015
`System.in.read()` blocks until it faces the EOL character(s). This cannot be easily emulated because that behaviour is implemented in native code. The first attempt was sending -1 after the end of each text or line. This is an insufficient solution because -1 indicates the end of the stream. It seems that the blocking behaviour is mainly needed for code that uses Scanner (which uses `System.in.read(byte[], int, int)` internally.) Hence the -1 hack was replaced by an enhanced implementation of `read(byte[], int, int)` that returns the whole next line. Fixes #35.
stefanbirkner
added a commit
that referenced
this issue
Dec 7, 2015
`System.in.read()` blocks until it faces the EOL character(s). This cannot be easily emulated because that behaviour is implemented in native code. The first attempt was sending -1 after the end of each text or line. This is an insufficient solution because -1 indicates the end of the stream. It seems that the blocking behaviour is mainly needed for code that uses Scanner (which uses `System.in.read(byte[], int, int)` internally.) Hence the -1 hack was replaced by an enhanced implementation of `read(byte[], int, int)` that returns the whole next line. Fixes #35.
stefanbirkner
added a commit
that referenced
this issue
Dec 9, 2015
`System.in.read()` blocks until it faces the EOL character(s). This cannot be easily emulated because that behaviour is implemented in native code. The first attempt was sending -1 after the end of each text or line. This is an insufficient solution because -1 indicates the end of the stream. It seems that the blocking behaviour is mainly needed for code that uses Scanner (which uses `System.in.read(byte[], int, int)` internally.) Hence the -1 hack was replaced by an enhanced implementation of `read(byte[], int, int)` that returns the whole next line. Fixes #35.
stefanbirkner
added a commit
that referenced
this issue
Dec 9, 2015
`System.in.read()` blocks until it faces the EOL character(s). This cannot be easily emulated because that behaviour is implemented in native code. The first attempt was sending -1 after the end of each text or line. This is an insufficient solution because -1 indicates the end of the stream. It seems that the blocking behaviour is mainly needed for code that uses Scanner (which uses `System.in.read(byte[], int, int)` internally.) Hence the -1 hack was replaced by an enhanced implementation of `read(byte[], int, int)` that returns the whole next line. Fixes #35.
stefanbirkner
added a commit
that referenced
this issue
Dec 10, 2015
`System.in.read()` blocks until it faces the EOL character(s). This cannot be easily emulated because that behaviour is implemented in native code. The first attempt was sending -1 after the end of each text or line. This is an insufficient solution because -1 indicates the end of the stream. It seems that the blocking behaviour is mainly needed for code that uses Scanner (which uses `System.in.read(byte[], int, int)` internally.) Hence the -1 hack was replaced by an enhanced implementation of `read(byte[], int, int)` that returns the whole next line. Fixes #35.
stefanbirkner
added a commit
that referenced
this issue
Dec 10, 2015
`System.in.read()` blocks until it faces the EOL character(s). This cannot be easily emulated because that behaviour is implemented in native code. The first attempt was sending -1 after the end of each text or line. This is an insufficient solution because -1 indicates the end of the stream. It seems that the blocking behaviour is mainly needed for code that uses Scanner (which uses `System.in.read(byte[], int, int)` internally.) Hence the -1 hack was replaced by an enhanced implementation of `read(byte[], int, int)` that returns the whole next line. Fixes #35.
stefanbirkner
added a commit
that referenced
this issue
Dec 11, 2015
`System.in.read()` blocks until it faces the EOL character(s). This cannot be easily emulated because that behaviour is implemented in native code. The first attempt was sending -1 after the end of each text or line. This is an insufficient solution because -1 indicates the end of the stream. It seems that the blocking behaviour is mainly needed for code that uses Scanner (which uses `System.in.read(byte[], int, int)` internally.) Hence the -1 hack was replaced by an enhanced implementation of `read(byte[], int, int)` that returns the whole next line. Fixes #35.
stefanbirkner
added a commit
that referenced
this issue
Dec 15, 2015
`System.in.read()` blocks until it faces the EOL character(s). This cannot be easily emulated because that behaviour is implemented in native code. The first attempt was sending -1 after the end of each text or line. This is an insufficient solution because -1 indicates the end of the stream. It seems that the blocking behaviour is mainly needed for code that uses Scanner (which uses `System.in.read(byte[], int, int)` internally.) Hence the -1 hack was replaced by an enhanced implementation of `read(byte[], int, int)` that returns the whole next line. Fixes #35.
stefanbirkner
added a commit
that referenced
this issue
Dec 16, 2015
`System.in.read()` blocks until it faces the EOL character(s). This cannot be easily emulated because that behaviour is implemented in native code. The first attempt was sending -1 after the end of each text or line. This is an insufficient solution because -1 indicates the end of the stream. It seems that the blocking behaviour is mainly needed for code that uses Scanner (which uses `System.in.read(byte[], int, int)` internally.) Hence the -1 hack was replaced by an enhanced implementation of `read(byte[], int, int)` that returns the whole next line. Fixes #35.
stefanbirkner
added a commit
that referenced
this issue
Dec 16, 2015
`System.in.read()` blocks until it faces the EOL character(s). This cannot be easily emulated because that behaviour is implemented in native code. The first attempt was sending -1 after the end of each text or line. This is an insufficient solution because -1 indicates the end of the stream. It seems that the blocking behaviour is mainly needed for code that uses Scanner (which uses `System.in.read(byte[], int, int)` internally.) Hence the -1 hack was replaced by an enhanced implementation of `read(byte[], int, int)` that returns the whole next line. Fixes #35.
stefanbirkner
added a commit
that referenced
this issue
Dec 16, 2015
`System.in.read()` blocks until it faces the EOL character(s). This cannot be easily emulated because that behaviour is implemented in native code. The first attempt was sending -1 after the end of each text or line. This is an insufficient solution because -1 indicates the end of the stream. It seems that the blocking behaviour is mainly needed for code that uses Scanner (which uses `System.in.read(byte[], int, int)` internally.) Hence the -1 hack was replaced by an enhanced implementation of `read(byte[], int, int)` that returns the whole next line. Fixes #35.
stefanbirkner
added a commit
that referenced
this issue
Dec 16, 2015
`System.in.read()` blocks until it faces the EOL character(s). This cannot be easily emulated because that behaviour is implemented in native code. The first attempt was sending -1 after the end of each text or line. This is an insufficient solution because -1 indicates the end of the stream. It seems that the blocking behaviour is mainly needed for code that uses Scanner (which uses `System.in.read(byte[], int, int)` internally.) Hence the -1 hack was replaced by an enhanced implementation of `read(byte[], int, int)` that returns the whole next line. Fixes #35.
|
Hi, it almost works well, but I still have problems with some use case where it seems that instead of blocking, System.in returns -1 (in a java Reader)… I would expect that the reader blocks until the test using the rule is ended… |
|
Maybe I'm not using TextFromStandardInputStream as it is meant… I realised that calling provideLines multiple times would replace the previous lines provided if they hadn't been read yet… |
|
I try to find a better solution by using |
|
I could imagine how to implement blocking behaviour for a test where the code that reads runs in a different thread than the test code. But I never encountered such a test. Could you provide more details about the use case that still has problems with |
|
We exactly do that: we run the tested code inside its own thread. See for example: http://fisheye.ow2.org/browse/Petals/petals/client-tools/petals-cli/petals-cli/src/test/java/org/ow2/petals/cli/MainTest.java?r=38790#to261 I think maybe TextFromStandardInputStream is not meant to be something to test that… maybe it would make sense to introduce something different that would block and actually act like System.in? |
|
This is what I wrote to achieve that functionality: http://fisheye.ow2.org/browse/Petals/petals/client-tools/petals-cli/petals-cli-base-junit/src/main/java/org/ow2/petals/cli/base/junit/rules/ConsoleInput.java?r=38790&r=38790 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I am using JLine (version 2.6) and it seems it doesn't interact well with TextFromStandardInputStream.
Basically, the jline.console.ConsoleReader provides a method called readLine() that reads a line and when it returns null, it means the stream was ended (InputStreamReader.read() returns -1 if I understood well).
The thing is when using TextFromStandardInputStream, once what had to be read from System.in was read, it seems that instead of blocking, InputStreamReader.read() returns -1…
I'm not totally sure the cause is not coming from JLine, but when I tried to implement my own TextFromStandardInputStream by simply replacing System.in with a PipedInputStream to which I write, it worked as desired...
The text was updated successfully, but these errors were encountered: