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
