Paste non-ASCII character causes Mojibake (garbled text)

[oneonestar]

Pasting a relatively long string with non-ASCII character into trino-cli causes part of the string becomes Mojibake (garbled text).

jline reads 64 bytes at a time. It will then decode that 64 bytes using CharsetDecoder.
When pasting a line contains more that 64bytes, it will repeat the above action until the end.

For non-ASCII character using UTF-8, a code point could take 1-4 bytes. For example, one Japanese character usually takes 3 bytes. If we paste 22 Japanese characters into trino-cli, that string is 22*3byte = 66 bytes. The last character will be broken.

First 64 bytes read: 21 Japanese characters + 1st byte of the last character
=> the 1st byte then being dropped silently

Second 64 bytes read: 2nd & 3rd byte of the last character
=> failed to decode and becomes Mojibake

How to reproduce:
Paste 一二三四五六七八九〇一二三四五六七八九〇一二三 into trino-cli (without using the slow pasting feature provided by terminal).

Environment:

• trino-cli-388 & trino-cli-419
• jline 3.21.0
• MacOS Monterey 12.6.1
• iTerm2 Build 3.4.19

Jun 15, 2023 11:41:59 AM org.jline.utils.Log logr
FINE: Registering shutdown-hook: Thread[JLine Shutdown Hook,5,main]
Jun 15, 2023 11:41:59 AM org.jline.utils.Log logr
FINE: Adding shutdown-hook task: org.jline.terminal.impl.PosixSysTerminal$$Lambda$81/0x0000000801098da8@14a2f921
Jun 15, 2023 11:41:59 AM org.jline.utils.Log logr
FINE: Using terminal PosixSysTerminal
Jun 15, 2023 11:41:59 AM org.jline.utils.Log logr
FINE: Using pty OsXNativePty

Looks like #782 fixed this issue unintentional(?).
The old problematic codes are below:

jline3/terminal/src/main/java/org/jline/utils/NonBlocking.java

Lines 212 to 219 in 43c6014

	byte[] buf = new byte[b.length];
	int l = input.readBuffered(buf);
	if (l < 0) {
	return l;
	} else {
	ByteBuffer bytes = ByteBuffer.wrap(buf, 0, l);
	CharBuffer chars = CharBuffer.wrap(b);
	decoder.decode(bytes, chars, false);

Update jline to 3.22.0 fixed this issue on my machine.
I report this issue just in case to prevent regression in the future.
Feel free to close this issue if this is not a problem anymore.

Ref: trinodb/trino#17916 trinodb/trino#17915

[gnodet]

Closing as solved in 3.22.0