I replaced sun.io converters by an adaptor to sun.nio.cs coders

[Ulf Zibis]

Hi Sherman,

your answer is short, so I assume you are in heavy work.
Thanks for your code sample. BTW, ByteToCharNIOAdaptor.java had no 
content, but anyway, it's informative to learn from your code. I could 
see details, I oversaw.
It's funny, that on my first approach I choosed the same names for the 
classes. Later I merged them together with XToYConverter's, as there is 
no more need to have them as abstract base class.
In your code I also discovered some deficits:
(1) It's not compatible to always throw IndexOutOfBoundsException, if 
the preconditions on the offset and length parameters do not hold, as 
XToYConverter's hehave different.
(2) You don't reuse the x-Buffer's for consecutive invocations of convert.
(3) In case of unmappable, you don't set badInputLength = cr.length()
(4) In case of overflow in flush(), you don't set charOff = 0
Also you reengineered xAll() and xAny() methods, which I didn't.
Helpful for me was, to reset encoder in catch block.

So I merged all aspects together:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/io/

Please also not my integration of XToYConverter's in Converter class.

-Ulf



Am 15.09.2008 18:45, Xueming Shen schrieb:
> Ulf Zibis wrote:
>> Hi Sherman,
>>
>>
>> I see only 1 solution: ByteToCharConverter#flush() should first 
>> invoke decoder.decode(src, dst, true) before decoder.flush(), because 
>> there is no compatible endOfInput-logic in sun.io package.
>> In this context, I must admit, that I don't understand the necessity 
>> of  this endOfInput-logic. It forces an additional invocation of 
>> encodeLoop() even if there is nothing to do in most cases. Why can't 
>> decoder.flush() do this job as in sun.io package???
>>
>
>
> Attached are the code I wrote back to 2006 when we were struggling 
> whether or not to remove
> the whole sun.io package. This is only a "prototype" for the proposal, 
> so I did not even test it...
> yes, I finally dug it out to see what I dealt with back them:-)
>
> X-code(buffer, buffer, boolean) and flush() have different 
> role/functionality.
>
> We do have some mapping testing cases for sun.io package, but I've not 
> yet pushed them to the
> "open" area of JDK7.
>
> sherman