David M. Lloyd
david.lloyd at redhat.com
Thu Sep 15 15:47:44 UTC 2016
On 09/15/2016 02:06 AM, Xueming Shen wrote:
> -1 :-)
> Console is supposed to be a "char/String" based class, "encoding" really
> have no business here in its api. Simply for some implementation
> 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
> together with its siblings, file,encoding and another "supposed to be
> property sun.jnu.encoding.
> On 9/14/16, 11:42 PM, Aleksey Shipilev wrote:
>> Claes pointed out that our own reflective hacks to figure out console
>> encoding do not work anymore . 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?
More information about the core-libs-dev