<i18n dev> Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7

[Jason Mehrens]

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.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
> 
> http://cr.openjdk.java.net/~sherman/6995537/webrev
> 
> Sherman
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120209/e456cff3/attachment.html