Mikhail Loenko wrote:
2006/4/26, Andrew Zhang <[EMAIL PROTECTED]>:
Vladimir Strigun wrote:
On 4/26/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
I try to find best solution for Harmony-166 and during fix preparation
I've found current issue.
Method test_read from tests.api.java.io.InputStreamReaderTest failed
and first fix I've created was with in.available() but I agree with
Mikhail that it's possible not the best solution.
why?
Yes, the spec says "The available method for class InputStream always
returns 0.". But it also says "This method should be overridden by
subclasses.". :)
Here's the available description:
"Returns the number of bytes that can be read (or skipped over) from
this input stream without blocking by the next caller of a method for
this input stream."
If someone writes a subclass of InputStream that available returns 0
even if there are some data available, then he should take the result of
cheating or contradicting with spec.
What if someone just unable to say if the bytes are available?
For example, he reads something from a hardware module and
the only way to know whether there are bytes is try reading?
I'm a little confused.
How does solution 2 handle this problem?
Thanks,
Mikhail
In current implementation of InputStreamReader endOfInput variable
sets to true if reader can't read less that 8192 bytes. When
InputStreamReader try to read one character from
LimitedByteArrayInputStream (A ByteArrayInputStream that only returns
a single byte per read) true as a parameter passed to charset decoder,
nevertheless we still have further input from
LimitedByteArrayInputStream.
2 methods from tests.api.java.io.OutputStreamWriterTest also failed
because of read() method implementation of InputStreamReader.
IMO, we have 2 ways to fix Harmony-166 :
1. Don't change the behavior of CharsetDecoder, and use in.available()
method for endOfInput variable. If in.available() > 0 pass false to
decoder, read additional one byte from input stream and try to decode
again. If decoding operation can decode remaining portion + one
additional byte to character, stop here, else try to read addition
byte again. Function fillBuf will invoke with the next invocation of
read() method and next portion of 8192 bytes will be read from input
stream.
It's reasonable.
After all, streaming decode is useful and helpful to users.
IMO, streaming decode is a highlight compared with some RI :)
2. Change the behavior of CharsetDecoder and operate with
bytes.remaining() for calculating endOfInput. In this case, we always
pass false with first invocation of decode method. Algorithm further
is almost the same as above, but we stop the cycle if all bytes
decoded successfully (i.e if bytes.hasRemaining() is false).
Vladimir, Could you please give the detail code or pseudo code of these
two solutions?
Thanks!
What do you think about it?
Thanks.
Vladimir.
Thanks!
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
