On Fri, 6 Jun 2025 08:42:40 GMT, Alan Bateman <al...@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
