cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [Design] JXTG 2.0 (first stab after reading the archives)
Date Sun, 05 Dec 2004 15:38:36 GMT
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.


View raw message