harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deven You <devyo...@gmail.com>
Subject Fwd: [jira] Commented: (HARMONY-6590) [classlib][luni]A issue about CharsetEncoder.flush() in the OutputStreamWriter.close()
Date Tue, 20 Jul 2010 03:16:08 GMT
Hi Tim,
I have write a test case which simulate the behavior of OutputStreamWriter
and fail on RI but pass on harmony trunk.
import java.nio.ByteBuffer;
import java.nio.charset.Charset;
import java.nio.charset.CharsetEncoder;
import java.nio.charset.CodingErrorAction;
import java.security.AccessController;

import org.apache.harmony.luni.util.PriviAction;

public class TestCharsetEncoderFlush {
 private static ByteBuffer bytes = ByteBuffer.allocate(8192);
    private static CharsetEncoder encoder;

public static void main(String[] args) {
String encoding = AccessController
.doPrivileged(new PriviAction<String>(
"file.encoding", "ISO8859_1")); //$NON-NLS-1$ //$NON-NLS-2$
encoder = Charset.forName(encoding).newEncoder();
encoder.onMalformedInput(CodingErrorAction.REPLACE);
encoder.onUnmappableCharacter(CodingErrorAction.REPLACE);
 encoder.flush(bytes);
 System.out.println("should not reach here");

}

}

RI output:
Exception in thread "main" java.lang.IllegalStateException: Current state =
RESET, new state = FLUSHED
at
java.nio.charset.CharsetEncoder.throwIllegalStateException(CharsetEncoder.java:951)
at java.nio.charset.CharsetEncoder.flush(CharsetEncoder.java:640)
at
ydw.arena7.luni.test.TestCharsetEncoderFlush.main(TestCharsetEncoderFlush.java:27)
Harmony trunk output:
should not reach here

It proves our CharsetEncoder indeed does not follow the spec and RI. I will
create a jira with this test case and figure out how to solve this problem.
>From the spec, seems we need track every step of  CharsetEncoder invocation,
but it looks silly, dose anyone have better suggestion for this problem.
Thanks a lot!

---------- Forwarded message ----------
From: Tim Ellison (JIRA) <jira@apache.org>
Date: 2010/7/19
Subject: [jira] Commented: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWriter.close()
To: devyoudw@gmail.com



   [
https://issues.apache.org/jira/browse/HARMONY-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889841#action_12889841]

Tim Ellison commented on HARMONY-6590:
--------------------------------------

Interesting that this code does not fail on the RI, note that the encoder is
in the 'wrong' state.

       OutputStream os = new ByteArrayOutputStream();
       CharsetEncoder cse = Charset.defaultCharset().newEncoder();
       cse.encode(CharBuffer.wrap("Simple"), ByteBuffer.allocate(42),
false);
       OutputStreamWriter bw = new OutputStreamWriter(os, cse);
       bw.flush();
       bw.close();

Maybe the flush() doesn't flush the encoder.

> [classlib][luni]A issue about CharsetEncoder.flush() in the
OutputStreamWriter.close()
>
--------------------------------------------------------------------------------------
>
>                 Key: HARMONY-6590
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6590
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>    Affects Versions: 5.0M14
>            Reporter: deven you
>            Assignee: Tim Ellison
>         Attachments: HARMONY-6590.diff
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> Today I read through the OutputStreamWrtier.close() code below:
>     public void close() throws IOException {
>         synchronized (lock) {
>             if (encoder != null) {
>                 encoder.flush(bytes);
>                 flush();
>                 out.flush();
>                 out.close();
>                 encoder = null;
>                 bytes = null;
>             }
>         }
>     }
> I remember the java spec says for the CharsetEncoder.flush():
IllegalStateException - If the previous step of the current encoding
operation was an invocation neither of the reset method nor of the
three-argument encode method with a value of true for the endOfInput
parameter.
> Obviously OutputStreamWrtier.close() does not check this prerequisite
before invoking the encoder.flush(bytes). So I write a test case[1] to check
this issue but it passed, I think it is because our CharsetEncoder.flush()
does not follow the spec.
> Though I think our OutputStreamWrtier.close() should modify to follow the
spec. I have put the patch[1] on this jira.
> And I will also look into the CharsetEncoder.flush() to investigate this
problem.
> [1] see the attached patch

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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