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...@hotmail.com
CC: core-libs-...@openjdk.java.net; i18n-dev@openjdk.java.net
Subject: Re: Codereview request for 6995537: different behavior in iso-2022-jp
encoding between jdk131/140/141 and jdk142/5/6/7
Jason,
I might be misunderstanding your suggestion, but the current implementation of
OutputStreamWriter.flushBuffer()/StreamWriter.implFlushBuffer() does not flush
the encoder, so even the caller can choose when to invoke flushBuffer(), it does
not solve the problem (flush() invokes flushBuffer() before it flushes the "out"
stream). The proposed the change is to put back the encoder.flush() into
osw.flushBuffer (in StreamWriter.implFlushBuffer()).
-Sherman
On 02/09/2012 10:24 AM, Jason Mehrens wrote:
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 by a zero len if
condition in StreamEncoder.write(char[], int, int). That seems inconsistent.
If that check was removed then the workaround would be:
===================
ByteArrayOutputStream bos = new ByteArrayOutputStream();
String str = "\u6700";
OutputStreamWriter osw = new OutputStreamWriter(bos, "iso-2022-jp");
osw.write(str, 0, str.length());
osw.write(""); //Flush buffer.
osw.flush(); //Flush stream.
==================
It's not pretty but, it would allow the caller to choose when flushBuffer is
called.
Jason
> Date: Wed, 8 Feb 2012 22:26:54 -0800
> From: xueming.s...@oracle.com
> To: core-libs-...@openjdk.java.net; i18n-dev@openjdk.java.net
> Subject: Codereview request for 6995537: different behavior in iso-2022-jp
> encoding between jdk131/140/141 and jdk142/5/6/7
>
> The solution is to re-store the "flush the encoder" mechanism in
> StreamEncoder's flushBuffer().
>
> I have been hesitated to make this change for a while, mostly because
> this regressed behavior
> has been their for 3 releases, and the change triggers yet another
> "behavior change". But given
> there is no obvious workaround and it only changes the behavior of the
> charsets with this
> shift in/out mechanism, mainly the iso-2022 family and those IBM
> EBCDIC_DBCS charsets, I
> decided to give it a try.
>
> Here is the webreview
>
> http://cr.openjdk.java.net/~sherman/6995537/webrev
>
> Sherman
>
