harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deven You <devyo...@gmail.com>
Subject [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 05:24:02 GMT
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>.
 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()
)
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)

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!

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?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message