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
>
