I just imported into jakarta-commons-sandbox a component named
Thread Benchmark (TBM). It is designed to make testing thread
synchronization problems easier and as a clearing house for identifying
thread synchronization problems, workarounds, and alternative solutions.
The proposal can be found
Several people, prodded by Glenn Nielson, discussed putting together a
project to overcome the shortcoming of Date and Calendar, ranging from
their pita to use-ness to their massive performance bottlenecks.
I know Glenn has had the flu so don't think he has gotten the ball
rolling, but this
I am preparing the way to move the www.joda.org time code to Apache. There is no doubt
that it fits well with commons, but I am also wary given the changing nature of
Jakarta at present.
This doesn't exclude changes to DateUtils, but should limit the expansion on that
class. (DateUtils should
Joda is a great project, but is of a very different tack than what
Glenn brought up -- Glenn, that is your cue -- which is that Date and
Calendar are A) very broken, and B) very embedded in lots of places.
If projects are willing to use the Joda library instead of the standard
library that is
I am preparing the way to move the www.joda.org time code to Apache. There
is no doubt that it fits well with commons, but I am also wary given the
changing nature of Jakarta at present.
I agree with everything up to the last clause. What is your concern?
--- Noel
There are discussions over Apache-commons, over commit rights within Jakarta, the size
of jakarta-commons (and sustainability of growth), willingness to allow new comitters
to just work on sandbox code, the role of the sandbox, the incubator, the list seems
to go on. With 1/3 of all dev mails
Although apparantly simple, all date methods and concepts get complex very
quickly. For example timezone handling and daylight savings handling. These
methods don't feel like the right additions to DateUtils at the moment.
Stephen
- Original Message -
From: Ash .. [EMAIL PROTECTED]
The
