Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray()

Xueming Shen xueming.shen at oracle.com
Fri Apr 29 00:11:41 UTC 2011


On 04-28-2011 3:46 PM, Ulf Zibis wrote:
>
>> It's safe to say that java.nio.cs.StandardCharset is not for 
>> String.getBytes()/toCharArray()
>> only, so the fact that "cs" variant of 
>> String.getBytes()/toCharArray() is "slower" than its "csn"
>> variant arguably might not be a very strong/supportive material for 
>> that discussion:-)
> So what prevents us from the same caching optimization in ZipCoder 
> etc. class ?
>

What do you want to cache in ZipCoder? Each ZipFile object holds one 
ZipCoder object and
uses it for its coding need through its lifetime. And ZipCoder does 
"remember" its de/encoder.

>
> - ZipCoder.isutf8 is unreadeable. Better: isUTF8
>

Updated to isUTF8 as suggested.


> - ArrayDecoder.decode(ba, 0, length, ca) could throw 
> MalformedInput/UnmappableCharacterException instead returning -1. 
> Benefits:
> -- prevent from translating -1 to 
> IllegalArgumentException("MALFORMED") in ZipCoder etc.
> -- more precise exception
>

Something we might consider to do in jdk8 or jdk7 updates. But for now I 
don't want to
change ArrayDecoder/Encoder interface at this stage, otherwise I will 
have to touch those
SingleByte charsets and the StringCoding class as well, those SingleByte 
charsets now
only handle/assume "replace" action and the StringCoding does not expect 
MalformedInput
or UnmappableCharacterException.

-Sherman


>
> -Ulf
>




More information about the core-libs-dev mailing list