Isn't it a catch 22? How can you build on something that isn't stable? We risk creating API wrappers that break when Java Time goes through a revision. Stephen has solicited much feedback and at times things do change (like class renamings).
Paul On Tue, Jul 7, 2009 at 11:21 AM, Craig L Russell<craig.russ...@sun.com> wrote: > Hi Paul, > > I might not understand the intent of the Commons Time stuff, but I assumed > that it's stuff that doesn't belong in the Time package itself but builds on > Time. > > The idea of building it now while the JSR is still incomplete is to provide > some features now and not wait possibly years before the JSR completes. > > Craig > > On Jul 7, 2009, at 9:09 AM, Paul Benedict wrote: > >> Perhaps we're approaching this wrong. If we need common utilities for >> a JSR that's yet to be released, why not submit them straight to >> Stephen? I don't see why Apache should take this on while the JSR >> isn't finished. >> >> On Tue, Jul 7, 2009 at 10:59 AM, Craig L Russell<craig.russ...@sun.com> >> wrote: >>> >>> Hi Henri, >>> >>> On Jul 7, 2009, at 12:16 AM, Henri Yandell wrote: >>> >>>> Until the new time stuff is in Java - I'm hesistant to have it in >>>> Lang. Yet I also don't want to do anymore work on Date based code in >>>> Lang :) >>> >>> It might be years before there's an update to Java SE (Sun/Oracle's >>> intentions regarding a new JSR in which 310 would go aren't at all >>> clear). >>> >>> If stuff in Lang is supposed to be in sync with Java SE, maybe not good >>> to >>> put Time in there. >>> >>> But I don't see any issues with a new Commons Time sub-project. I'd hope >>> that Commons Time would move faster than Java SE anyway... >>> >>> Craig >>>> >>>> On Sat, Jul 4, 2009 at 7:42 AM, Paul Benedict<pbened...@apache.org> >>>> wrote: >>>>> >>>>> I'd rather see it in Commons Lang. >>>>> >>>>> On Fri, Jul 3, 2009 at 4:09 PM, Henri Yandell<flame...@gmail.com> >>>>> wrote: >>>>>> >>>>>> Pondering an idea of a Commons Time package that would sit on top of >>>>>> Joda Time/JSR 310. Lang's time package functionality would go in >>>>>> there, along with various enhancement ideas. The less core stuff than >>>>>> the JSR handles. Items like: >>>>>> >>>>>> * DateSequence, which would handle an open issue [LANG-347] for a >>>>>> 'addWeekDays' type item. Rather than adding and changing the date, you >>>>>> would walk along the sequence and get the date. Or something. >>>>>> * RandomDate [LANG-350] >>>>>> * DateFormatUtils >>>>>> * DateUtils (definitely rewritten on top of Joda) >>>>>> * DurationFormatUtils (likewise) >>>>>> * FastDateFormat >>>>>> >>>>>> Probably not StopWatch. >>>>>> >>>>>> Anyway, pondering people's thoughts; plus any info Stephen might have >>>>>> on whether this is insane or not :) >>>>>> >>>>>> Hen >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> Craig L Russell >>> Architect, Sun Java Enterprise System http://db.apache.org/jdo >>> 408 276-5638 mailto:craig.russ...@sun.com >>> P.S. A good JDO? O, Gasp! >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > Craig L Russell > Architect, Sun Java Enterprise System http://db.apache.org/jdo > 408 276-5638 mailto:craig.russ...@sun.com > P.S. A good JDO? O, Gasp! > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
