First, IMHO it's not a bad consolidation of steps that basically always come together - printing a prompt, suppressing a new line, immediately followed by the readLine() call.
However, I would not consider changing it right now if I didn't step on the following anomaly.
While trying to integrate jline support into the native TerminalConsole I observed a very weird behavior. When I used the readLine API that takes a prompt as an argument, everything behaved correctly. If I did it in two steps, printing the prompt first and calling prompt-less readLine() method next, the line editing (back space) could remove the prompt as it were a part of the entered string itself.
To avoid that behavior we would need either report a bug with jline and wait for a resolution or change our "readLine" to take the prompt.
The gist of the change is to add the "prompt" argument to the "readLine" API:
First, IMHO it's not a bad consolidation of steps that basically always come together - printing a prompt, suppressing a new line, immediately followed by the readLine() call.
However, I would not consider changing it right now if I didn't step on the following anomaly.
While trying to integrate jline support into the native TerminalConsole I observed a very weird behavior. When I used the readLine API that takes a prompt as an argument, everything behaved correctly. If I did it in two steps, printing the prompt first and calling prompt-less readLine() method next, the line editing (back space) could remove the prompt as it were a part of the entered string itself.
To avoid that behavior we would need either report a bug with jline and wait for a resolution or change our "readLine" to take the prompt.