RFR: 8356985: Use "stdin.encoding" in Console's read*() methods [v2]
Naoto Sato
naoto at openjdk.org
Tue May 20 22:06:52 UTC 2025
On Tue, 20 May 2025 11:29:42 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:
>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Reflects review comments
>
> test/jdk/java/io/Console/StdinEncodingTest.java line 46:
>
>> 44: * @run junit StdinEncodingTest
>> 45: */
>> 46: public class StdinEncodingTest {
>
> AFAICT, there is no similar test (e.g., one using a mock `CharsetProvider`) for `stdout.encoding`. Will it be addressed by another ticket? Shall we consider adding a similar `StdoutEncodingTest` too? (Not necessarily in this PR.)
`stdout.encoding` validity is tested through the public `charset()` mehtod, which is in `CharsetTest.java`
> test/jdk/java/io/Console/csp/provider/MockCharsetProvider.java line 83:
>
>> 81: while (in.remaining() > 0) {
>> 82: char c = (char)in.get();
>> 83: if (c != '\n') {
>
> `Character.toUpperCase('\n') == '\n'`, not? If so, do we still need this `if`-branching?
Eliminating newlines was a hack to ignore them in the expect responses so that it can check the combined output in one shot. Now I think it is better to check the result separately, so modified as such.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098947409
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098947338
More information about the core-libs-dev
mailing list