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<--
Just FYI...
Here is a corresponding ICU4JNI bug: http://bugs.icu-project.org/cgi-bin/icu-bugs/conversion?id=5179