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