harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Ellison (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-6590) [classlib][luni]A issue about CharsetEncoder.flush() in the OutputStreamWriter.close()
Date Mon, 19 Jul 2010 12:30:49 GMT

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

Tim Ellison commented on HARMONY-6590:


The test passes ok for me, both on the latest code and 5.0M14.  Can you share your error to
show how the flush failed?

Reading the code, we always call encoder.encode(...) with "true" for end of input, so either:
 - the flush is failing with the encoder in state INIT, should be unusual but may be a misbehaving
 - the encoder we are passed as an argument in the constructor is not in a safe state to flush.

> [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.

View raw message