commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [LANG] change FormatCache.getDateTimeInstance() to use int
Date Sat, 04 Jun 2011 18:00:28 GMT
On 4 June 2011 18:35, Henri Yandell <> wrote:
> Seems good. Something other than NULL probably; and probably should
> come up with some bizarre negative number to stay out of the way of
> any future JDK items.

Yes, that is a possible issue here. The current JDK only uses positive
integers, so -1 may be OK.

FormatCache already has the following constant:

     * No date or no time.  Used in same parameters as
DateFormat.SHORT or DateFormat.LONG
    static final int NONE= -1;

This is not currently used, but perhaps should be made public and used for this.

Choosing a suitable value is either as simple as leaving it at -1 or
it could be impossible.
Every int value may mean something to someone (*), and the JDK writers
may choose to use the same bizarre number in future...

Alternatively, we do away with the special null code and have 3 methods:


This would solve the issue with no possible clashes, and does not
affect the external API AFAICT.

Another related issue - not sure why FastDateFormat creates aliases
for the DateFormat constants:

     * FULL locale dependent date or time style.
    public static final int FULL = DateFormat.FULL;

Why not just use the originals? If new values are added, at the very
least the Javadoc will have to be changed.

(*) especially if their name is Ramanujan ;-)

> On Fri, Jun 3, 2011 at 8:06 PM, sebb <> wrote:
>> On 4 June 2011 03:44, Henri Yandell <> 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 <> 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:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message