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
