Re: [Design] JXTG 2.0 (first stab after reading the archives)

["Roy G. Biv" <mi...@pcextremist.com>]

>Bruno Dumon wrote:
>>On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
>>
>>>CForms Convertor Integration
>>>----------------------------
>>>
>>>Here is the Convertor interface:

<snip/>

>>>AFAICS we don't need the formatCache in a convertion component, each 
>>>convertor will only be needed to be defined once
>>>    
>>>
>>
>>The purpose of the formatCache is if a lot of values need to be
>>converted using the same convertor, which is (or can be) the case in
>>selection lists. Java's DateFormat and NumberFormat classes are not
>>thread-safe,
>>
>Ok. didn't know that, disturbing :/
>
>> so they need to be recreated for each conversion, and this
>>can be quite heavy (eg the number or date formatting pattern must be
>>reparsed each time). The format cache allows to store the prepared
>>Date/NumberFormat instance, but is completely optional.
>>  
>>
>Yes, now it makes perfect sense. Would it be possible to let the 
>convertor manager handle some thread local Date/NumberFormat cache, so 
>that the user of the convertor doesn't have to manage that?

Wasn't this precisely why java.text.Format implements Cloneable?

eg. formatter.clone().format(...)

The idea was that the pattern would not have to be reparsed.  In addition,
threadsafe formatters could simply return "this" as the return value to
clone().

Would this be less efficient than a format cache?  It would definitely be
simpler code and a modern generational garbage collector should make short
work of the short-lived object.


- Miles Elam

P.S. Yes, reading the discussion makes me feel more at ease.  I still
think the email subject could have been clearer though.  ;-)

Re: [Design] JXTG 2.0 (first stab after reading the archives)

[Daniel Fagerstrom <da...@nada.kth.se>]

Roy G. Biv wrote:
>> Bruno Dumon wrote:
>>
>>> On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
>>>
>>>> CForms Convertor Integration
>>>> ----------------------------
>>>>
>>>> Here is the Convertor interface:
> 
> 
> <snip/>
> 
>>>> AFAICS we don't need the formatCache in a convertion component, each 
>>>> convertor will only be needed to be defined once
>>>>   
>>>
>>>
>>> The purpose of the formatCache is if a lot of values need to be
>>> converted using the same convertor, which is (or can be) the case in
>>> selection lists. Java's DateFormat and NumberFormat classes are not
>>> thread-safe,
>>>
>> Ok. didn't know that, disturbing :/
>>
>>> so they need to be recreated for each conversion, and this
>>> can be quite heavy (eg the number or date formatting pattern must be
>>> reparsed each time). The format cache allows to store the prepared
>>> Date/NumberFormat instance, but is completely optional.
>>>  
>>>
>> Yes, now it makes perfect sense. Would it be possible to let the 
>> convertor manager handle some thread local Date/NumberFormat cache, so 
>> that the user of the convertor doesn't have to manage that?
> 
> 
> Wasn't this precisely why java.text.Format implements Cloneable?
> 
> eg. formatter.clone().format(...)
> 
> The idea was that the pattern would not have to be reparsed.  In addition,
> threadsafe formatters could simply return "this" as the return value to
> clone().
> 
> Would this be less efficient than a format cache?  It would definitely be
> simpler code and a modern generational garbage collector should make short
> work of the short-lived object.

Seem like an nice and efficient solution, it would take away the 
complexity with external cache or thread local cache. I'm no expert on 
performance aspects in Java, though, so I would be interested in what 
others think.

/Daniel