You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "deven you (JIRA)" <ji...@apache.org> on 2010/07/16 08:19:49 UTC
[jira] Created: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWrtier.close()
[classlib][luni]A issue about CharsetEncoder.flush() in the OutputStreamWrtier.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
Fix For: 5.0M14
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.
[jira] Updated: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWrtier.close()
Posted by "deven you (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
deven you updated HARMONY-6590:
-------------------------------
Attachment: HARMONY-6590.diff
> [classlib][luni]A issue about CharsetEncoder.flush() in the OutputStreamWrtier.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
> Fix For: 5.0M14
>
> 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.
[jira] Commented: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWriter.close()
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892806#action_12892806 ]
Hudson commented on HARMONY-6590:
---------------------------------
Integrated in Harmony-1.5-head-linux-x86_64 #909 (See [http://hudson.zones.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/909/])
> [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.
[jira] Commented: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWriter.close()
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891580#action_12891580 ]
Tim Ellison commented on HARMONY-6590:
--------------------------------------
So I think this issue has been resolved by the fix to CharsetEncoder.
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.OutputStreamWriter;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
import java.nio.charset.Charset;
import java.nio.charset.CharsetEncoder;
import java.nio.charset.CoderResult;
public class OSWTest {
static class MyCharsetEncoder extends CharsetEncoder {
protected MyCharsetEncoder(Charset cs, float averageBytesPerChar,
float maxBytesPerChar) {
super(cs, averageBytesPerChar, maxBytesPerChar);
}
public MyCharsetEncoder() {
this(Charset.forName("UTF-8"), 2.0f, 4.0f);
}
@Override
protected CoderResult encodeLoop(CharBuffer in, ByteBuffer out) {
int l = in.length();
for (int i = 0; i < l; i++) {
out.putChar(in.get());
}
return CoderResult.UNDERFLOW;
}
@Override
protected CoderResult implFlush(ByteBuffer out) {
System.out.println("Feeling flushed");
return CoderResult.UNDERFLOW;
}
}
public static void main(String[] args) throws IOException {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
OutputStreamWriter osw = new OutputStreamWriter(bos, new MyCharsetEncoder());
osw.flush();
osw.write("Hello Harmony!");
osw.flush();
osw.close();
System.out.println(bos.toString());
}
}
> [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.
[jira] Closed: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWriter.close()
Posted by "deven you (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
deven you closed HARMONY-6590.
------------------------------
Tim
I totally agree with you and have verified this fix. Thanks a lot
> [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.
[jira] Commented: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWriter.close()
Posted by "deven you (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890166#action_12890166 ]
deven you commented on HARMONY-6590:
------------------------------------
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!
> [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.
[jira] Updated: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWriter.close()
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison updated HARMONY-6590:
---------------------------------
Summary: [classlib][luni]A issue about CharsetEncoder.flush() in the OutputStreamWriter.close() (was: [classlib][luni]A issue about CharsetEncoder.flush() in the OutputStreamWrtier.close())
Fix Version/s: (was: 5.0M14)
> [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.
[jira] Commented: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWriter.close()
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWriter.close()
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ 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:
--------------------------------------
Deven,
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 impl
- 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.
[jira] Assigned: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWrtier.close()
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison reassigned HARMONY-6590:
------------------------------------
Assignee: Tim Ellison
> [classlib][luni]A issue about CharsetEncoder.flush() in the OutputStreamWrtier.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.
[jira] Commented: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWriter.close()
Posted by "deven you (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891974#action_12891974 ]
deven you commented on HARMONY-6590:
------------------------------------
2010/7/23 Tim Ellison (JIRA) <ji...@apache.org>
osw.flush() has no problem, it does not call encoder.flush(), the problem is
in the osw.close() which directly call encoder.flush() without checking
the prerequisites. If you only keep the osw.close() as below:
public static void main(String[] args) throws IOException {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
OutputStreamWriter osw = new OutputStreamWriter(bos, new
MyCharsetEncoder());
osw.close();
Then harmony trunk will throw IllegalStateException now (since HARMONY-6594
has been applied), meanwhile RI5/RI6 won't throw this exception.
HARMONY-6590 just fix this regression caused by HARMONY-6594. Thanks a lot!
> [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.
[jira] Resolved: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWriter.close()
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison resolved HARMONY-6590.
----------------------------------
Fix Version/s: 5.0M15
Resolution: Fixed
Thanks Deven.
Looking at the proposed patch, we call encoder.flush() but don't look at the return code.
The spec says:
"If this method completes successfully then it returns CoderResult.UNDERFLOW. If there is insufficient room in the output buffer then it returns CoderResult.OVERFLOW. If this happens then this method must be invoked again, with an output buffer that has more room, in order to complete the current encoding operation. "
I modified the code to do this, so please check you agree. I also renamed the local variable to make it clear what was going to be flushed.
The patch was applied at r979647. Please verify this fixes the issue for you.
> [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.
[jira] Commented: (HARMONY-6590) [classlib][luni]A issue about
CharsetEncoder.flush() in the OutputStreamWriter.close()
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ 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.