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

[Volkan Yazici]

On Fri, 6 Jun 2025 08:42:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 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.

_I think_ 😅 I see your point, and I agree with it. I've dropped several of my earlier changes from the abandoned parent #25368 – this applies to all subsequent tickets: #25544 (core), #25541 (tools), and this one. When the subject code is called in a `Process`, or the stream is obtained from a `URL` or a `ClassLoader`, ..., when it is _"obvious"_ that the stream doesn't refer to the console, I've skipped the `stdin.encoding` refactoring. That said, _"obvious"_ is very subjective and I might have misjudged certain usages.

> The tests that do read from System.in probably need closer examination to see if they are reading from a pipe or something else.

In all `stdin.encoding` PRs – #25544 (core), #25541 (tools), and this one – I've examined usages before introducing the changes. I did my best, but I cannot claim it was exhaustive. That said, if it requires a significant effort to deduce that the console is not involved in a `System.in` usage, I'd prefer to include the `stdin.encoding` best-practice. There is a considerable likelihood that a later change could inadvertently violate that subtle assumption.

@AlanBateman, if you think a particular change needs closer examination or needs to be reverted, please say so. I'd be more than happy to carry out that task.

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

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