<i18n dev> [8]Review request for 7200341: DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some circumstances

Naoto Sato naoto.sato at oracle.com
Fri Oct 5 11:13:46 PDT 2012


Thanks. I modified the fix according to your comments. The new webrev is 
located at:

http://cr.openjdk.java.net/~naoto/7200341/webrev.01/

Please review.

Naoto

On 10/4/12 10:36 PM, Masayoshi Okutsu wrote:
> The fix will have a problem when called by multiple threads. Strictly
> speaking, DateFormatSymbols isn't thread-safe, but the usage of
> cachedHashCode will have a problem even with no set* calls.
>
> I'd suggest the following.
>
>     int hashCode =cachedHashCode;
>     if (hashCode == 0) {
>         ...
>         cachedHashCode = hashCode;
>     }
>     return hashCode;
>
> And cachedHashCode needs to be volatile. And when a DateFormatSymbols is
> mutated, the cachedHashCode value needs to be reset.
>
> Masayoshi
>
> On 10/5/2012 6:44 AM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix for the following bug:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7200341
>>
>> Proposed changes are located at:
>>
>> http://cr.openjdk.java.net/~naoto/7200341/webrev.00/
>>
>> The fix is to re-implement hashCode() correctly. It now also takes all
>> the fields into consideration for hash code calculation.
>>
>> Naoto
>



More information about the i18n-dev mailing list