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?)
I weigh heavily the inclusion of JSR-310 in the JSE in the near future.
Yet it's clearly still in flux, so it may be wise to use Joda-Time
now. I can imagine at some point in the not-too-distant future that
using the JSE classes will become standard practice, so having a
migration strategy makes sense to me.
Our use case is indeed simple, and I was thinking the wrapper API would
be simple enough to justify itself in terms of both convenience and time
provider abstraction. Convenience use cases might include support for
natural language time periods like "3 hours," which is not supported by
either JSR-310 or Joda-Time afaict.
We should probably just look at whether JodaTime is simple enough to
configure in Spring (and gives us what we need).
I'm fairly certain that's the case.
> If not, we should just write a simple API to encapsulate the minimal
set we need.
This is more or less what I was suggesting, but from a different
perspective.
M
--
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
