RFR: 8357993: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [hotspot] [v2]

[Alan Bateman]

On Fri, 6 Jun 2025 07:21:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman @plummercj @sspitsyn Thanks so much for taking time to review the changes, much appreciated. 🙇
>
>> @AlanBateman @plummercj @sspitsyn Thanks so much for taking time to review the changes, much appreciated.
> 
> Okay, but I'm still puzzled as to why the tests were changed as they don't ready from the console.

> @AlanBateman, I only skipped the practice of passing `stdin.encoding` to `InputStreamReader`/`Scanner` ctors whenever it is obvious that the `System.in` referred there is not the console. Do you imply I was mistaken while assessing `BindServer` and `attach010Agent00`? If so, which ones, and [to learn what I missed] why? I can create a follow-up ticket+PR to amend them.

Tests are automated and very rare to have tests read from an interactive console. A small number of test uses "expect" for testing interactive input. There might be tests that have stdin redirected from a file or something else.

For multi VM tests (very common in the test suite) then you typically see the parent process using Process/ProcessBuilder and starting a child VM with its standard streams connected to the parent, meaning reading from System.in will read from a pipe connected to the parent. Some tests do inherit but I doubt we have any tests that inherit and also read from an interactive console.

So my point is that we probably don't need to jump on all tests that use System.in. The tests that do read from System.in probably need closer examination to see if they are reading from a pipe or something else.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2948526535