[ https://issues.apache.org/jira/browse/HARMONY-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892785#action_12892785 ] Hudson commented on HARMONY-6590: --------------------------------- Integrated in Harmony-select-1.5-head-linux-x86_64 #75 (See [http://hudson.zones.apache.org/hudson/job/Harmony-select-1.5-head-linux-x86_64/75/]) > [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 > Fix For: 5.0M15 > > 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.