harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-308) [classlib][nio charset] java.nio.charset.Charset.encode(CharBuffer) returns bytes in a different order in Harmony and RI for the UTF-16 charset
Date Tue, 12 Dec 2006 12:20:23 GMT
     [ http://issues.apache.org/jira/browse/HARMONY-308?page=all ]

Alexei Zakharov updated HARMONY-308:
------------------------------------

    Summary: [classlib][nio charset] java.nio.charset.Charset.encode(CharBuffer) returns bytes
in a different order in Harmony and RI for the UTF-16 charset  (was: [classlib][nio] java.nio.charset.Charset.encode(CharBuffer)
returns bytes in a different order in Harmony and RI for the UTF-16 charset)

> [classlib][nio charset] java.nio.charset.Charset.encode(CharBuffer) returns bytes in
a different order in Harmony and RI for the UTF-16 charset
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-308
>                 URL: http://issues.apache.org/jira/browse/HARMONY-308
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>            Reporter: Dmitry M. Kononov
>         Attachments: test9.java
>
>
> java.nio.charset.Charset.encode(CharBuffer) returns bytes in a different order.
> Please look at the output of a test case that I am going to attach.
> RI:
> ---8<---
> bb.order()=BE
> cb.order()=LE
> result.order()=BE
> The result is
> result = java.nio.HeapByteBuffer[pos=0 lim=28 cap=52]
> bb = java.nio.HeapByteBuffer[pos=0 lim=28 cap=28]
> The result is OK.
> ---8<---
> Harmony (At revision 391577):
> ---8<---
> bb.order()=BE
> cb.order()=LE
> result.order()=BE
> The result is
> result = java.nio.ReadWriteHeapByteBuffer, status: capacity=28 position=0 limit=28
> bb = java.nio.ReadWriteHeapByteBuffer, status: capacity=28 position=0 limit=28
> The result is not correct.
> 0 elements are not equal (ffffffff != fffffffe)
> 1 elements are not equal (fffffffe != ffffffff)
> 2 elements are not equal (1b != 4)
> 3 elements are not equal (4 != 1b)
> 4 elements are not equal (35 != 4)
> 5 elements are not equal (4 != 35)
> 6 elements are not equal (42 != 4)
> 7 elements are not equal (4 != 42)
> 8 elements are not equal (3e != 4)
> 9 elements are not equal (4 != 3e)
> 10 elements are not equal (20 != 0)
> 11 elements are not equal (0 != 20)
> 12 elements are not equal (32 != 4)
> 13 elements are not equal (4 != 32)
> 14 elements are not equal (20 != 0)
> 15 elements are not equal (0 != 20)
> 16 elements are not equal (20 != 4)
> 17 elements are not equal (4 != 20)
> 18 elements are not equal (3e != 4)
> 19 elements are not equal (4 != 3e)
> 20 elements are not equal (41 != 4)
> 21 elements are not equal (4 != 41)
> 22 elements are not equal (41 != 4)
> 23 elements are not equal (4 != 41)
> 24 elements are not equal (38 != 4)
> 25 elements are not equal (4 != 38)
> 26 elements are not equal (38 != 4)
> 27 elements are not equal (4 != 38)
> ---8<---

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message