Adding a wrapper doesn't help us too much I don't think (its not like we'd swap time implementations for something this simple, would we?)
We should probably just look at whether JodaTime is simple enough to configure in Spring (and gives us what we need). If not, we should just write a simple API to encapsulate the minimal set we need. Cheers, Scott On Mon, Mar 19, 2012 at 10:05 AM, Marvin Addison <marvin.addi...@gmail.com>wrote: > > We should evaluate if they are stable enough for us to use. > > I believe the following thread answers the API stability question and > also provides some insight into the timeline for appearance in the JSE: > > http://sourceforge.net/mailarchive/message.php?msg_id=28777248 > > I believe the following sentences are worth repeating here: > > "For early adopters this is unfortunate, but I have to place > inclusion in the JDK at a higher priority than maintaining any kind of > compatability with the current source-base. That said, the main APIs > of the main classes is likely to stay roughly the same, even if in > another package." > > I think it's pretty clear that the API is still in flux, although in > practice it may manifest as package changes more than anything else. > > I'm thinking a wrapper strategy might serve us best here, providing the > flexibility to use the time library that makes sense now with an option > to change in the future with minimal impact to the CAS codebase as a whole. > > M > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
