On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote:
>> `java.io.Console` uses the charset specified by the `stdout.encoding` system
>> property for both input and output. While this is generally sufficient,
>> since Console is intended for interactive terminal use, some platforms allow
>> diff
On Mon, 26 May 2025 07:18:59 GMT, Alan Bateman wrote:
> I assume you've done some "test repeat" jobs to ensure that any variance in
> the version of "expect" on test machines doesn't cause any issues.
Actually I have not. Thanks for reminding. So I ran this through our internal
CI on Linux x64
On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote:
>> `java.io.Console` uses the charset specified by the `stdout.encoding` system
>> property for both input and output. While this is generally sufficient,
>> since Console is intended for interactive terminal use, some platforms allow
>> diff
On Wed, 21 May 2025 16:48:44 GMT, Naoto Sato wrote:
>> Created jline/jline3#1282.
>
> Thanks!
JLine seems to incorporate the stdin encoding already, which is quick!
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2105219623
On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote:
>> `java.io.Console` uses the charset specified by the `stdout.encoding` system
>> property for both input and output. While this is generally sufficient,
>> since Console is intended for interactive terminal use, some platforms allow
>> diff
On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote:
>> `java.io.Console` uses the charset specified by the `stdout.encoding` system
>> property for both input and output. While this is generally sufficient,
>> since Console is intended for interactive terminal use, some platforms allow
>> diff
On Fri, 23 May 2025 17:18:40 GMT, Stuart Marks wrote:
> > Can they even possibly do so?
>
> Sure, as far as I know, IntelliJ IDEA runs on its own version of the JDK, and
> it can easily be invoked or modified to allow use of those modules. I took a
> quick look at NetBeans and didn't see any r
On Fri, 23 May 2025 16:26:36 GMT, Naoto Sato wrote:
> Can they even possibly do so?
Sure, as far as I know, IntelliJ IDEA runs on its own version of the JDK, and
it can easily be invoked or modified to allow use of those modules. I took a
quick look at NetBeans and didn't see any references to
On Fri, 23 May 2025 03:47:32 GMT, Stuart Marks wrote:
> But... do the IDEs use this to interface to implement their in-IDE terminal
> emulator?
Can they even possibly do so? `java.base`'s `module-info` exports
`jdk.internal.io` only to `jdk.internal.le` and `jdk.jshell`, so I think no
other
On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote:
>> `java.io.Console` uses the charset specified by the `stdout.encoding` system
>> property for both input and output. While this is generally sufficient,
>> since Console is intended for interactive terminal use, some platforms allow
>> diff
On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote:
>> `java.io.Console` uses the charset specified by the `stdout.encoding` system
>> property for both input and output. While this is generally sufficient,
>> since Console is intended for interactive terminal use, some platforms allow
>> diff
On Thu, 22 May 2025 16:39:46 GMT, Alan Bateman wrote:
>> I'm confused by the actual behavior here. What might be helpful is to divide
>> the discussion between a) what charsets get used for input and output, and
>> b) the return value of the `charset()` method.
>>
>> I'm not entirely sure, but
> `java.io.Console` uses the charset specified by the `stdout.encoding` system
> property for both input and output. While this is generally sufficient, since
> Console is intended for interactive terminal use, some platforms allow
> different encodings to be configured for input and output. In
On Thu, 22 May 2025 16:15:56 GMT, Stuart Marks wrote:
>> Good point. Brought the same wording to the `charset()` method description
>> for further clarification.
>
> I'm confused by the actual behavior here. What might be helpful is to divide
> the discussion between a) what charsets get used f
On Wed, 21 May 2025 16:48:20 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/io/Console.java line 67:
>>
>>> 65: * stdout.encoding}, in which case read operations use the {@code
>>> Charset}
>>> 66: * designated by {@code stdin.encoding}.
>>> 67: *
>>
>> `Console.charset()` stat
On Wed, 21 May 2025 19:29:08 GMT, Naoto Sato wrote:
>> `java.io.Console` uses the charset specified by the `stdout.encoding` system
>> property for both input and output. While this is generally sufficient,
>> since Console is intended for interactive terminal use, some platforms allow
>> diff
On Wed, 21 May 2025 18:07:39 GMT, Justin Lu wrote:
>>> There is script.exp, but it tests sun.stdout.encoding, not stdout.encoding.
>>
>> It is addressed in this PR
>
> I think the JBS bug ID needs to be added to `CharsetTest.java` as well then.
Bugid added to the test. Additionally replaced tes
On Wed, 21 May 2025 16:54:22 GMT, Naoto Sato wrote:
>> Actually providing mock charset was a workaround of not having public method
>> for getting the input encoding. I think it would be an overkill to introduce
>> a new public method because it will not be used much, as most cases are
>> suff
> `java.io.Console` uses the charset specified by the `stdout.encoding` system
> property for both input and output. While this is generally sufficient, since
> Console is intended for interactive terminal use, some platforms allow
> different encodings to be configured for input and output. In
On Wed, 21 May 2025 06:12:18 GMT, Justin Lu wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflects review comments
>
> src/java.base/share/classes/java/io/Console.java line 67:
>
>> 65: * stdout.encoding}, in whi
On Wed, 21 May 2025 16:53:53 GMT, Naoto Sato wrote:
>> Indeed there *are* `stdout.encoding` tests in `test/jdk/java/io/Console`,
>> yet none1 that thoroughly tests them with `expect` and a
>> dedicated (mock) `CharsetProvider` as you did here. FWIW, I really liked
>> your new test using a mock
On Wed, 21 May 2025 08:30:26 GMT, Volkan Yazici wrote:
>> `stdout.encoding` validity is tested through the public `charset()` mehtod,
>> which is in `CharsetTest.java`
>
> Indeed there *are* `stdout.encoding` tests in `test/jdk/java/io/Console`, yet
> none1 that thoroughly tests them with `expe
On Wed, 21 May 2025 08:20:50 GMT, Volkan Yazici wrote:
>> JLine is a 3rd party library. It would be desirable that they change their
>> implementation to separately handle in/out in their terminal, but that is
>> out of scope of this PR
>
> Created jline/jline3#1282.
Thanks!
-
PR
> `java.io.Console` uses the charset specified by the `stdout.encoding` system
> property for both input and output. While this is generally sufficient, since
> Console is intended for interactive terminal use, some platforms allow
> different encodings to be configured for input and output. In
On Tue, 20 May 2025 22:04:41 GMT, Naoto Sato wrote:
>> 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`)
>> f
On Tue, 20 May 2025 22:04:24 GMT, Naoto Sato wrote:
>> All `FileDescriptor.in` encounters in `jdk.internal.org.jline.terminal` that
>> might need attention:
>>
>> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/DumbTerminalProvider.java
>> src/jdk.internal.le/share/classe
On Tue, 20 May 2025 21:57:45 GMT, Naoto Sato wrote:
>> `java.io.Console` uses the charset specified by the `stdout.encoding` system
>> property for both input and output. While this is generally sufficient,
>> since Console is intended for interactive terminal use, some platforms allow
>> diff
On Tue, 20 May 2025 11:29:42 GMT, Volkan Yazici 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 StdinEncod
On Tue, 20 May 2025 19:24:16 GMT, Volkan Yazici wrote:
>> Also noticed `DumbTerminalProvider::sysTerminal` calls `DumbTerminal` with
>> `new FileInputStream(FileDescriptor.in)`. Later on `DumbTerminal` applies
>> `encoding()` both for passed `stdin` and `std{out,err}`. In short,
>> `TerminalPr
> `java.io.Console` uses the charset specified by the `stdout.encoding` system
> property for both input and output. While this is generally sufficient, since
> Console is intended for interactive terminal use, some platforms allow
> different encodings to be configured for input and output. In
On Tue, 20 May 2025 19:18:43 GMT, Volkan Yazici wrote:
>> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
>> line 160:
>>
>>> 158:
>>> 159: try {
>>> 160: Terminal terminal =
>>> TerminalBuilder.builder().encoding(outCharset)
>>
On Tue, 20 May 2025 10:40:39 GMT, Volkan Yazici wrote:
>> `java.io.Console` uses the charset specified by the `stdout.encoding` system
>> property for both input and output. While this is generally sufficient,
>> since Console is intended for interactive terminal use, some platforms allow
>> d
On Fri, 16 May 2025 18:11:39 GMT, Naoto Sato wrote:
> `java.io.Console` uses the charset specified by the `stdout.encoding` system
> property for both input and output. While this is generally sufficient, since
> Console is intended for interactive terminal use, some platforms allow
> differen
`java.io.Console` uses the charset specified by the `stdout.encoding` system
property for both input and output. While this is generally sufficient, since
Console is intended for interactive terminal use, some platforms allow
different encodings to be configured for input and output. In such cas
34 matches
Mail list logo
