On 29/09/2008, Mark Thomas <[EMAIL PROTECTED]> wrote:
> sebb wrote:
> > On 29/09/2008, Mark Thomas <[EMAIL PROTECTED]> wrote:
>
> >> ThreadLocals and container classloader environments need careful handling
> >> to avoid memory leaks.
> >
> > I would have thought that was a good reason to kee
sebb wrote:
> On 29/09/2008, Mark Thomas <[EMAIL PROTECTED]> wrote:
>> ThreadLocals and container classloader environments need careful handling
>> to avoid memory leaks.
>
> I would have thought that was a good reason to keep the class - one
> only needs to get the code right once?
If you don't
On 29/09/2008, Mark Thomas <[EMAIL PROTECTED]> wrote:
> sebb wrote:
> > BTW, Commons LANG has a thread-safe FastDateUtils which can be used
> > for formatting (but not parsing) dates.
>
> A whole jar for one method is somewhat overkill.
Indeed, but there's lots of other useful stuff in LANG.
I j
sebb wrote:
> BTW, Commons LANG has a thread-safe FastDateUtils which can be used
> for formatting (but not parsing) dates.
A whole jar for one method is somewhat overkill.
> Not sure why you did not just fix DateTool - e.g. by using ThreadLocal
> (or indeed synchronizing the use of DateFormats) -
BTW, Commons LANG has a thread-safe FastDateUtils which can be used
for formatting (but not parsing) dates.
Not sure why you did not just fix DateTool - e.g. by using ThreadLocal
(or indeed synchronizing the use of DateFormats) - rather than fixing
all calls to DateTool.
Or maybe I've misunderstoo
