cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy G. Biv" <mi...@pcextremist.com>
Subject Re: [Design] JXTG 2.0 (first stab after reading the archives)
Date Sun, 05 Dec 2004 02:25:56 GMT
>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.  ;-)



Mime
View raw message