commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: lang.time.* Was: [VOTE] Release of Commons Lang 2.0
Date Sun, 18 May 2003 22:37:50 GMT
Hello,

StopWatch is a great doo-dad, which I use, it'd be a shame to loose it. Are
we talking about discussing a .lang.time vs. a new commons-time? If not,
could we just decide which classes are (not) ready?

Gary

-----Original Message-----
From: Henri Yandell [mailto:bayard@generationjava.com] 
Sent: Sunday, May 18, 2003 15:19
To: Jakarta Commons Developers List
Subject: lang.time.* Was: [VOTE] Release of Commons Lang 2.0



On Sun, 18 May 2003, Serge Knystautas wrote:

> Henri Yandell wrote:
> > lang.time is not ready yet.
>
> What's left to be done here?  I had submitted some of this right as 1.0
> was being released and was expecting it would be included in the next
> major release.  I was off this list for a bit, so was it discussed and
> rearranged?

Thanks for making me try to figure out why lang.time has been off the 2.0
release schedule since the beginning. Looking back at the mails, I think
it is because there was the usual debate over whether lang.time should be
in Lang or in Commons Time. Where does the end of lang.time's scope get
drawn.

Currently lang.time is made up of 4 classes, all from different
developmers.

Serge's CalendarUtils is devoted to providing improved functionality for
Calendar objects, and through them Dates.
Ant's DateUtils has a few methods for Dates, but probably should be
wrapped into CalendarUtils/DateFormatUtils.
FastDateFormat is an improved rewrite of SimpleDateFormat taken from the
TreeTrove project.
StopWatch is a time utility for recording periods of time. Mainly I find
this useful for benchmarking.

All have unit tests.

I'm quite confident that CalendarUtils and StopWatch fit nicely in
lang.time. FastDateFormat too unless a Commons Text component were to
arrive. DateUtils I think should be broken up/folded into CalendarUtils.

The biggest reason for not having lang.time in the release is that it
still needs debate. So the question is:

Should we work on lang.time before 2.0? How much work is in there? There's
a Bugzilla issue for improvements to StopWatch. DateUtils needs
butchering [imo anyway]. Anything else?

Additionally, would there be any versioning issues with lang.time
appearing in Lang 2.1?

Hen


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message