commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject RE: Date/Time should not be in [lang]
Date Thu, 19 Dec 2002 21:06:32 GMT

Rather than what Charles suggests, I would prefer to take Stephen out for
a beer, get him drunk and get him to submit JODA Time to Jakarta Commons.

The Lang.time part is intended to be a small set of helpers for Date
stuff, but it might grow. I think Charles' point is valid, but unfounded
yet.

Lets worry about getting it coded and then decide what goes in the next
Lang version. We've a lot of controversial bits and I know that I for one
intend to have a debate later about just what is right and ready for the
next Lang release.

How does that sound?

Hen


On Thu, 19 Dec 2002 EPugh@upstate.com wrote:

> Charles,
>
> I think you raise a good point, but taken to the nth degree, you soon end up
> with a jar per package or class!  I think the idea is that lang is supposed
> to have all those useful bits and pieces that you need frequently, but maybe
> not always.  A couple classes that arguable should be removed would be the
> RadomStringUtils and lang.enum package!
>
> I am not 100% disagreeing with you, but while the scope of the package is
> just 3 classes or less, making it a seperate Jar seems like an increase in
> overall work to maintain and deal with these classes.
>
> Now, if this package where to grow into 5 or six packages and 10 or 30
> classes, then I would definitly agree with breaking it out.  Also, if we did
> want weird/unusal stuff like getPhaseOfMoon() then this would make sense as
> well.  However, then you could just use Joda...
>
> Just my 2 cents however...
>
> Eric
>
> -----Original Message-----
> From: Charles Burdick [mailto:charles_burdick@yahoo.com]
> Sent: Thursday, December 19, 2002 2:33 PM
> To: Jakarta Commons Developers List
> Subject: Date/Time should not be in [lang]
>
>
> I haven't read the various Date/Time threads completely.  (Cuz there's
> over 50 in just the last few days!)
>
> But to me, putting these "Utils" into [lang] is a *bad idea*.
>
> This is the perfect opportunity to utilize the Commons charter with its
> focus on well-defined common components.  Everyone agrees it would be
> great to have a new implementation of Calendar and DateFormat that's
> not on crack like Sun's.
>
> However, I don't see any correlation with the rest of [lang].  Where is
> the common use and common change that involves the rest of [lang]?  How
> would these date/time items depend on other parts of [lang]?
>
> I always thought it was weird and problematic that Sun slapped Date and
> Calendar in [util] but DateFormat was in [text].  To me, if Commons
> packages date/time objects in [lang], we're just repeating bad
> practices.
>
> I'd much rather have an independent [DATE] or [TIME] or [DATETIME]
> package.  Simple, clearly defined.  If you need to use 'em, you import
> JAR, if you don't, you don't.
>
> Thanks,
> Chuck
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>


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


Mime
View raw message