On Wed, 9 Apr 2025 10:46:40 GMT, Alan Bateman <[email protected]> wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rewrite bits about charset decoding, removing mention of "internal
>> objects."
>
> src/java.base/share/classes/java/lang/IO.java line 42:
>
>> 40: * {@code System.in} into characters. The charset used for decoding is
>> specified by the
>> 41: * {@link System#getProperties stdin.encoding} property. If this
>> property is not present,
>> 42: * or if the charset it names cannot be loaded, then UTF-8 is used
>> instead.
>
> stdout.encoding and stderr.encoding are specified (in System.getProperties)
> to lead to unspecified behavior if started with either property set to a
> value other than UTF-8. We should work through the issues of introducing
> stdin.encoding as soon as we can, esp. the redirect cases and whether there
> is use cases for setting any of these properties on the command line.
Yes, believe it or not, I am still studying this...
> src/java.base/share/classes/java/lang/IO.java line 47:
>
>> 45: * Decoding may buffer additional bytes beyond those that have been
>> decoded to characters
>> 46: * returned to the application. After the first call to one of the
>> {@code readln} methods,
>> 47: * any subsequent use of {@code System.in} results in unspecified
>> behavior.
>
> I wonder if we should add a note about mixing API usage into System.in too.
> There are tutorials and books that show examples build on System.in that will
> add buffering on that input source.
Might be a good idea. I'll handle this separately. I don't want it to refer to
a Preview API. I'll probably just use Scanner and InputStreamReader as examples.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035772247
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2035773250
