harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][nio_cahr] Issue about CharsetEncdoer.flush() does not follow the spec and RI5 also doesn't follow the spec
Date Wed, 21 Jul 2010 10:14:03 GMT
On 21/Jul/2010 06:24, Deven You wrote:
> See https://issues.apache.org/jira/browse/HARMONY-6594
> <https://issues.apache.org/jira/browse/HARMONY-6594>
> In Java5 Spec, the flush() method should always be invoked after reset() or the
> three-argument encode<http://../../../java/nio/charset/CharsetEncoder.html#encode(java.nio.CharBuffer,+java.nio.ByteBuffer,+boolean)>
>  method with a value of true for the endOfInput parameter, otherwise, an
> IllegalStateException will be throwed. Harmony's implementation does not
> implement this logic, when an encoder is created and followed by calling its
> flush() method,  flush() should throw IllegalStateException. I have fix
> previous case with
> HARMONY-6594<https://issues.apache.org/jira/browse/HARMONY-6594>.

I wonder if we shouldn't just take a pragmatic view on this one.

I can see why flush() wouldn't make sense during an encoding until all
the data has been received, but I see no reason why the flush() of a
newly created encoder should fail, and I'd be very surprised if anyone
actually relies on this behavior.

>  However I checked that RI5 also  does not completely follow the spec.  For
> the invocation sequence: reset -> encode with 3 arguments -> reset  ->
> flush, RI5 throw IlegalStateException against the spec.
> (seeorg.apache.harmony.nio_char.tests.java.nio.charset.ASCIICharsetEncoderTest.testInternalState_Flushed()
> )

Same as above, the reset() should put the encoder back to its starting
state -- whereupon I'd expect a flush() to do nothing.

> and sequence: encode(Charbuffer) -> flush(), RI5 doesn't throw
> IlegalStateException against the spec. (after encode(Charbuffer), the
> encoder should be in FLUSH state)
>  (see seeorg.apache.harmony.nio_char.tests.java.nio.charset.ASCIICharsetEncoderTest.testInternalState_from_Encode)

Again, despite the spec, the behavior you observe of flush()-ing twice
not being an error sounds reasonable to me.  In this case I definitely
think we should follow the behavior rather than the spec. as it is more
likely to occur in normal usage.

> Further Investigation shows from Java6 Spec, this behavior is changed, it
> says  flush() will throw IllegalStateException if the previous step of the
> current encoding operation was an invocation neither of the
> flush<http://../../../java/nio/charset/CharsetEncoder.html#flush(java.nio.ByteBuffer)>
>  method nor of the three-argument
> encode<http://../../../java/nio/charset/CharsetEncoder.html#encode(java.nio.CharBuffer,+java.nio.ByteBuffer,+boolean)>
>  method with a value of true for the endOfInput parameter. And actually, RI5
> follows the java6 spec rather than java5!

I'm guessing the spec was updated to reflect the desired behavior -- so
I'd go for matching the Java 6 behavior in both Harmony 5 and Harmony 6
streams.

> So now I am confused if we should modify our harmony trunk CharsetEncoder to
> comply with the java5 spec or in other hand modify it to comply with RI5 and
> java6 spec for above 2 cases? Anyone could give me some suggestions for this
> point?

What does Java 6 do for flush()-ing a
 - newly created encoder?
 - a reset encoder?

Regards,
Tim

Mime
View raw message