[FIXED] System.in.read() with different results in Eclipse and Netbeans

Issue

I'm trying the following code in Eclipse and NetBeans:

while (true) 
    System.out.println(System.in.read());

This code prints the code associated with the typed characters and works correctly in the two commented IDEs.

They work the same except when you press enter. In NetBeans it returns the value 10 and in Eclipse the values ​​13 and 10.

For example, if I press the key a (ASCII 97) and Enter, the output is as follows:

NetBeans: 97 10 Eclipse: 97 13 10

Why do they work differently? Could Eclipse be configured to give the same output as NetBeans? Thank you very much

Solution

Why do they work differently?

Well, they are different products implemented by different people. So why would you expect them to be the same.

Presumably, the Eclipse team decided that their IDE's console emulator should use the OS platform's line separator (\r\n), and the Netbeans team thought that the UNIX / Linux way was a better idea.

Why? Ask the implementors!

Which is correct? That's a matter of opinion.

---

Could Eclipse be configured to give the same output as NetBeans?

I think you might have to customize the Eclipse key bindings in the Console context to do this. See http://help.eclipse.org/2022-06/index.jsp for details of Eclipse's key binding preferences.

There are some related options in the Console preferences, but I think they determine how control characters output by your application will be handled by the Eclipse console.

---

But frankly, I think you should be writing your applications to work with either form of line terminator sequence. That is what you would need to do if you were writing it to run outside of an IDE; i.e. from a real command shell.

There are various ways to get the platform line separator; e.g.

• Difference between System.getProperty("line.separator"); and "\n"?

Or you can write your input code to be "agnostic" ... like Scanner.readLine() and BufferedReader.readLine() are.

Answered By - Stephen C
Answer Checked By - David Marino (JavaFixing Volunteer)