summaryrefslogtreecommitdiff
path: root/include/ScopedJavaUnicodeString.h
diff options
context:
space:
mode:
authorPete Gillin <peteg@google.com>2017-07-17 11:26:53 +0100
committerPete Gillin <peteg@google.com>2017-07-18 13:32:18 +0000
commitc04007c41f7363f5f4cde7e19a582ac13adbc153 (patch)
treeb217a7a1c969bf732d6fdd7c8e22b9758c8eaf99 /include/ScopedJavaUnicodeString.h
parent4d8a37233981df346feb2be0651e0ed46719c159 (diff)
Fix the byte ordering behaviour of the UTF-16 Charset.
The behavioural change here is that the UTF-16 Charset (obtained via java.nio.charset.Charset.forName("UTF-16") or java.nio.charset.StandardCharsets.UTF_16) now encodes Strings into big-endian UTF-16 bytes with a byte-order marker, as the javadoc says it does. Previously, it encoded as little-endian with a byte-order marker. (Users wanting to encode as little-endian with a byte-order marker can use x-UTF-16LE-BOM.) The test changes are as follows. CharsetTest#test_UTF_16: This was suppressed. It now passes thanks to the above change, and we un-suppress it. CharsetTest#test_UTF_16BE and _UTF_16LE: These were suppressed. We remove the assertions about how it handles a reverse-BOM (i.e. a BOM with the wrong byte order), and un-suppress them. The javadoc doesn't specify how reverse-BOMs should be handled, so this change means we go from not testing anything to testing the specified behaviour. CharsetTest#test_x-UTF_16LE_BOM, _UTF_32, _UTF_32BE, UTF_32LE: These were suppressed. The javadoc doesn't mention these, but developers might reasonably expect them to exist and have sensible behaviour, and they do, so we make some tweaks to the assertions and remove the assertions about reverse-BOM-handling and un-suppress the tests. We also remove the 'hack' which prevented it testing that UTF-32 exists, since that doesn't seem to be needed any more. CharsetTest#test_X_UTF_32BE_BOM, _X_UTF_32LE_BOM: These were suppressed. We don't support these and don't expect to do so in the foreseeable future, so we just remove the tests. UTF16CharsetEncoderTest: Previously, this class overrode the assertByteArray method in its superclass so that, instead of asserting byte array equality, it just asserted that the byte arrays decoded to the same strings. This made this test almost endian-agnostic... although, presumably thanks to an oversight, testDefaultValue was actually asserting that UTF-16 encodes as LE. We remove the override and change the byte arrays so that the test now asserts that UTF-16 encodes as BE as required. OldCharset_MultiByte_UTF_16: This test asserts that UTF-16 encodes as BE, and was suppressed. We un-suppress it. OldCharset_MultiByte_UTF_16_Android: This test was a variant of the previous one what asserted that UTF-16 encodes as LE. We remove it. String2Test: Previously asserted that UTF-16 encodes as LE, now correctly asserts that it encodes as BE. Also slightly strengthened assertion. Bug: 2702411 Fixes: 2702411 Bug: 37074504 Fixes: 37074504 Test: cts-tradefed run cts -m CtsLibcoreTestCases -a arm64-v8a Change-Id: If174cd9ff0105008bd18a63e58ab3fa9a90c7475
Diffstat (limited to 'include/ScopedJavaUnicodeString.h')
0 files changed, 0 insertions, 0 deletions