Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7
jason_mehrens at hotmail.com
Thu Feb 9 20:07:36 UTC 2012
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.
Date: Thu, 9 Feb 2012 11:29:04 -0800
From: xueming.shen at oracle.com
To: jason_mehrens at hotmail.com
CC: core-libs-dev at openjdk.java.net; i18n-dev at 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
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()).
On 02/09/2012 10:24 AM, Jason Mehrens wrote:
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.
> Date: Wed, 8 Feb 2012 22:26:54 -0800
> From: xueming.shen at oracle.com
> To: core-libs-dev at openjdk.java.net; i18n-dev at 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
More information about the core-libs-dev