Java terminal app doesn't scan Cyrillic script.

[saiayn]

Windows Terminal version (or Windows build number)

Windows Terminal Version: 1.9.1942.0

Other Software

• Visual Studio Code Version: 1.60.0
• OS Version: Windows 10 Pro 10.0.19043 Build 19043
• Debugger for Java Version: 0.35.0
• Visual Studio Code Encoding: UTF-8
• Windows Encoding: UTF-8

Steps to reproduce

1. Copy and paste the following code.
   import java.util.Scanner;
class App {
public static void main(String[] args) {
Scanner input = new Scanner(System.in);
String wordCyrillic = input.nextLine();//!Привет
String wordLatin = input.nextLine(); //!hello
System.out.println("we print: " + wordCyrillic);
System.out.println("we print: " + wordLatin);
System.out.println("we print: " + "\u26a1\u2661");
System.out.println("we print: " + "Привет");
}
}
2. Run this code, inputting commented data(or use random Cyrillic letters).
3. You will get such output:
   

Expected Behavior

I expect it to scan the Cyrillic script properly as the Ubuntu terminal does.

Actual Behavior

Terminal doesn't scan the Cyrillic script at all.

[DHowett]

This looks like a problem in the Windows version of Java? Your screenshots illustrate that the Console and Terminal are properly passing input to Java when it is running under WSL (so: Linux java works fine! 😄)... so it seems like this is a "Java on Windows" bug.

You may need to file this upstream with them.

[saiayn]

so: Linux java works fine! 😄)... so it seems like this is a "Java on Windows" bug.

You may need to file this upstream with them.

Thanks for the quick reply, I can assume it's just a Java bug, but it does work fine in Eclipse/IntelliJ terminal.

By the way, as you can see on screenshot n.2 it doesn't really work correctly under WSL Ubuntu.
(Has some problems on "we print: " line n.2)

[ianjoneill]

I think this is probably related to / the same as #4551.

See a screenshot of it working below if you echo the Cyrillic text and then pipe it into the Java process (I removed the reading of the Latin string for ease of demo).

Source:

import java.nio.charset.StandardCharsets;
import java.util.Arrays;
import java.util.Scanner;

public class App {

  public static void main(String[] args) {
    Scanner input = new Scanner(System.in);
    String wordCyrillic = input.nextLine();//!Привет
    System.out.println("we print: " + wordCyrillic);
    System.out.println("Expected bytes " + Arrays.toString("!Привет ".getBytes(StandardCharsets.UTF_8)));
    System.out.println("Got bytes " + Arrays.toString(wordCyrillic.getBytes(StandardCharsets.UTF_8)));
    System.out.println("we print: " + "\u26a1\u2661");
    System.out.println("we print: " + "Привет");
  }
}

[ianjoneill]

Java does use ReadFile() under the hood to read from standard-in.

Standard-in is defined as a FileInputStream with a file descriptor of 0.
https://github.com/openjdk/jdk11u/blob/63fc945c1d4cdc893d89796804acfe0ce9341860/src/java.base/share/classes/java/lang/System.java#L1970-L1973

FileInputStream.readBytes() is implemented natively here:
https://github.com/openjdk/jdk11u/blob/63fc945c1d4cdc893d89796804acfe0ce9341860/src/java.base/share/native/libjava/FileInputStream.c#L69-L73

Which in turn calls another native method:
https://github.com/openjdk/jdk11u/blob/63fc945c1d4cdc893d89796804acfe0ce9341860/src/java.base/share/native/libjava/io_util.c#L73-L123

On line 109, it calls IO_Read(), which is #defined in a header to map to the function handleRead():
https://github.com/openjdk/jdk11u/blob/63fc945c1d4cdc893d89796804acfe0ce9341860/src/java.base/windows/native/libjava/io_util_md.h#L86

Which is implemented using ReadFile():
https://github.com/openjdk/jdk11u/blob/63fc945c1d4cdc893d89796804acfe0ce9341860/src/java.base/windows/native/libjava/io_util_md.c#L477-L500

[DHowett]

Thanks for all the comprehensive investigating! 😄 I'm going to call this a /dupe of #4551.

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!