On 2/10/2012 12:31 AM, Masayoshi Okutsu wrote:
I tend to agree with Sherman that the real problem is the
OutputStreamWriter API which isn't good enough to handle various
encodings. My understanding is that the charset API was introduced in
1.4 to deal with the limitations of the java.io and o
If you flush the stream while in the middle of writing a "character",
I would expect the results to be undefined, just as if you closed the
stream at that point. But at the end of a consistent set of data, I
would expect flush to behave like close, but without the actual closing
of the stream.
M
Sherman,
My mistake, I missed the fact that flushBuffer does not flush the encoder. I
incorrectly thought that write/print caused the encoder to flush and only the
direct call to OSW.flush did not.
Jason
Date: Thu, 9 Feb 2012 11:29:04 -0800
From: xueming.s...@oracle.com
To: jason_mehr.
Sherman,
As a workaround, what about allowing a write of empty string or empty char
array to call flushBuffer? If you call PrintStream.print("") then flushBuffer
is called on the internal writers. But if you try the same by doing
OuputStreamWriter.write("") the flushbuffer call is trapped b
I tend to agree with Sherman that the real problem is the
OutputStreamWriter API which isn't good enough to handle various
encodings. My understanding is that the charset API was introduced in
1.4 to deal with the limitations of the java.io and other encoding
handling issues.
I still don't th
