java - JLine NonBlockingReader 的契约(Contract)似乎已被破坏

Question

继my previous question之后关于JLine 。操作系统:W10，使用 Cygwin。

def terminal = org.jline.terminal.TerminalBuilder.builder().jna( true ).system( true ).build()
terminal.enterRawMode()
// NB the Terminal I get is class org.jline.terminal.impl.PosixSysTerminal
def reader = terminal.reader()
// class org.jline.utils.NonBlocking$NonBlockingInputStreamReader

def bytes = [] // NB class ArrayList
int readInt = -1
while( readInt != 13 && readInt != 10 ) {
    readInt = reader.read()
    byte convertedByte = (byte)readInt
    // see what the binary looks like:
    String binaryString = String.format("%8s", Integer.toBinaryString( convertedByte & 0xFF)).replace(' ', '0')
    println "binary |$binaryString|"
    bytes << (byte)readInt // NB means "append to list"

    // these seem to block forever, whatever the param... 
    // int peek = reader.peek( 50 ) 
    int peek = reader.peek( 0 )

}
// strip final byte (13 or 10)
bytes = bytes[0..-2]
def response = new String( (byte[])bytes.toArray(), 'UTF-8' )

根据 Javadoc(从源代码本地制作)peek 看起来像这样:

public int peek(long timeout)

Peeks to see if there is a byte waiting in the input stream without actually consuming the byte.

Parameters: timeout - The amount of time to wait, 0 == forever Returns: -1 on eof, -2 if the timeout expired with no available input or the character that was read (without consuming it).

它没有说明这里涉及什么时间单位...我假设是毫秒，但我也尝试过使用“1”，以防万一它是秒。

这个peek命令功能足够，因为它代表您能够检测多字节Unicode输入，并且具有一点超时的独创性:假设多字节的字节Unicode 字符的到达速度比人们输入的速度还要快...

但是，如果它永远不会解锁，则意味着您必须将 peek 命令放入超时机制中，您必须自行滚动该机制。下一个字符输入当然会解除阻塞。如果这是 Enter，则 while 循环将结束。但是，如果您想在输入下一个字符之前打印一个字符(或执行任何操作)，则 peek 的超时似乎不起作用，这会阻止您执行此操作。

Answer 1

尝试玩

 jshell> "𐐷 ẃ".getBytes()
 $1 ==> byte[8] { -16, -112, -112, -73, 32, -31, -70, -125 }

 jshell> "𐐷 ẃ".chars().toArray()
 $2 ==> int[4] { 55297, 56375, 32, 7811 }

 jshell> "𐐷 ẃ".codePoints() .toArray()
 $3 ==> int[3] { 66615, 32, 7811 }