On 4 June 2011 03:44, Henri Yandell <flame...@gmail.com> wrote: > Looking more at this one, it looks like the Integer is required as > null is a valid use case. So moving simply to int is out, but > rethinking it seems very doable.
I did some work on this, and I think we can add another style value which means don't use the date or time We don't require null, we just require a marker value that is not otherwise used. For example, define FastDateFormat.NULL = -1 and check for that. > Note that this isn't a public API; FormatCache is for now a > refactoring out of FastDateFormat to allow a later FastDateParser. > > I've added a TODO item to solve this before changing the class to public. > > Hen > > On Wed, May 18, 2011 at 6:37 AM, sebb <seb...@gmail.com> wrote: >> I think the method (new to 3.0) >> >> FormatCache.getDateTimeInstance(Integer dateStyle, Integer timeStyle, >> TimeZone timeZone, Locale locale) >> >> should be changed to use ints, as all the existing callers use ints. >> >> Furthermore, the parameters have to be unboxed in order to pass them >> to DateFormat, so the boxing/unboxing is unnecessary and wasteful. >> >> OK? >> >> I've not raised a JIRA for this because it is new code that has not >> been released - but I'm happy to do so if others think a JIRA entry is >> necessary here. >> >> --------------------------------------------------------------------- >> 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
