commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Date/Time should not be in [lang]
Date Thu, 19 Dec 2002 19:37:04 GMT

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...


-----Original Message-----
From: Charles Burdick []
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

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.


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

To unsubscribe, e-mail:
For additional commands, e-mail:

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