as long as there are no sets you can run concurrent reads on the
hashmap. and since the setters are only called when the application is
initialized we are ok.

-igor

On Mon, Feb 9, 2009 at 9:36 PM, Martin Makundi
<[email protected]> wrote:
>> which part of it is not threadsafe?
>
>        /** Maps Classes to ITypeConverters. */
>        private final Map<String, IConverter> classToConverter = new
> HashMap<String, IConverter>();
>
> The ConverterLocator.get(XX) can be used from multiple threads, can it
> not? In that case, the HashMap would not be thread-safe..?
>
> public final IConverter get(Class<?> c)
>        {
>                return classToConverter.get(c.getName());
>        }
>
> **
> Martin
>>
>> On Mon, Feb 9, 2009 at 9:32 AM, Martin Makundi
>> <[email protected]> wrote:
>>> Ok, then why Wicket's ConverterLocator is not thread safe? Or is it?
>>>
>>> **
>>> Martin
>>>
>>> 2009/2/9 Igor Vaynberg <[email protected]>:
>>>> yes, they need to be threadsafe if you cache them. numberformat itself
>>>> is also not threadsafe. another reason i can think of why we clone is
>>>> that a code that gets a bigdecimalconverter via getconverter() can
>>>> execute setters on it and modify it- which will affect the converter
>>>> globally. im not really sure how important the latter is since you
>>>> would have to downcast the interface, but still. perhaps some sort of
>>>> instance cache is in order.
>>>>
>>>> -igor
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to