RFC: System.console().encoding()

[David M. Lloyd]

On 09/15/2016 02:06 AM, Xueming Shen wrote:
> -1  :-)
>
> Console is supposed to be a "char/String" based class, "encoding" really
> should
> have no business here in its api. Simply for some implementation
> convenience
> is really not a good reason to add such a public method.

Let's look at the two likely cases fairly though: if the console is 
purely char-based it could easily report a Unicode-based encoding (like 
UTF-16_BE), implying full support for any string that is output or 
input.  If the console is byte-based, then the encoding definitely 
provides real, useful information that could be relevant to the 
application.  Overall it seems harmless to me.

> That said, I would be fine to have such informative info in the system
> properties,
> together with its siblings, file,encoding and another "supposed to be
> private"
> property sun.jnu.encoding.
>
> sherman
>
>
> On 9/14/16, 11:42 PM, Aleksey Shipilev wrote:
>> Hi,
>>
>> Claes pointed out that our own reflective hacks to figure out console
>> encoding do not work anymore [1]. But, we need the console encoding for
>> reliably printing on the console from within different sources. Note
>> that you would normally just use System.console() and its PrintWriter,
>> but reality is a bit more complicated, and sometimes you need to write
>> the plain char stream directly into the byte[]-accepting methods,
>> encoding on your own.
>>
>> So, my question: should we, in the light of extended Jigsaw-solving
>> crunch, provide the public Console.encoding() method that would return
>> the console charset?
>>
>> Thanks,
>> -Aleksey
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html
>>
>

-- 
- DML