> Console is supposed to be a "char/String" based class, "encoding" really > should have no business here in its api.
While I agree with your concerns about the functional side of the API, I disagree about this method having no practical use. I can give you a concrete example. The use case that we had was to check whether the "terminal" (console) would be able to handle non-ASCII characters. A Writer doesn't tell you anything. An encoding does provide at least some confidence that certain characters will be translated properly -- if your encoding is US-ASCII or ISO8859-1 then Polish diacritics won't get displayed for sure. This doesn't mean 100% confidence in actual glyph rendering of course, but it's a cheap and safe sanity check of the terminal's capabilities. An (undocumented) proprietary property? Sure, but I really don't see the reason why this shouldn't be in the API, unless you know of terminals that handle Unicode-based streams directly (in which case the encoding method would simply return UTF32). Dawid
