Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of t.p.ellison@gmail.com
 designates 209.85.214.49 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=unY9KvmjWBNUc11e77IciX8VwDl3LPHjHfYNal1l5sPRPspvuIBIGwmHasdXc3arNP
         3jbODYlG99eRl0aQvpl8QooeST8lUGob/dvCFIul1ZlNoYR/469iKvz8Th8zi+HwV7H6
         H3/vfEo/rcaHp8N/CHPQgBZow+PNBCtZ7O8r8=
Message-ID: <4C46D449.5000906@gmail.com>
Date: Wed, 21 Jul 2010 12:04:41 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: Fwd: [jira] Commented: (HARMONY-6590) [classlib][luni]A issue
 about 	CharsetEncoder.flush() in the OutputStreamWriter.close()
References: <18724063.410611279261189415.JavaMail.jira@thor>
	<8827247.452711279542950305.JavaMail.jira@thor>
 <AANLkTilIWb5woN3N-ZEwU0XOpI-TRNZvPQdJfUiT0iW3@mail.gmail.com>
In-Reply-To: <AANLkTilIWb5woN3N-ZEwU0XOpI-TRNZvPQdJfUiT0iW3@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 20/Jul/2010 04:16, Deven You wrote:
> Hi Tim,
> I have write a test case which simulate the behavior of OutputStreamWriter
> and fail on RI but pass on harmony trunk.

yes, and the discussion of how CharsetEncoder behaves is the first thing
-- but then we should look at how the OutputStreamWriter uses the
encoder.  Its not clear to me yet that there is a problem to fix in
OutputStreamWriter.

Regards,
Tim


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