[threeten-dev] zidtext parser

Xueming Shen xueming.shen at oracle.com
Fri Jan 25 12:24:33 PST 2013


Webrev has been updated accordingly.

It appears the most efficient place for the cache for the
combination of <locale, case, lenient, style> is  the
formatter itself? Most of the caching complicity come
from the combination of <locale, case [lenient]> which
are the fixed status for a particular formatter. The impl
now does not clone the printerparser list for withXXXXX()
though, so the printerparser-s get shared...we can address
this one later.

-Sherman

On 01/25/2013 03:34 AM, Stephen Colebourne wrote:
> Typo - "America/New_Work" ->  America/New_York
>
> The argument should not be an array (310 doesn't use arrays in APIs).
> A Set looks more appropriate.
>
> Since you validate all the strings anyway, it looks like it would be
> best to pass in a Set<ZoneId>?
>
> The internal variable in ZoneTextPrinterParser for the Set should be
> final for immutability.
>
> I tend to include the name of the data provider in the name of the
> method in the test case. So data_preferredZones() rather than
> provider_text()
>
> Stephen
>
>
> On 25 January 2013 01:40, Xueming Shen<xueming.shen at oracle.com>  wrote:
>> The webrev has been changed to add an appendZoneText(style, String[]
>> preferredZones)
>> method to the builder. It works as expected so far.
>>
>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/ztext_parser/
>>
>> The disadvantage is that the pattern formatter can't take advantage of this.
>> I'm not
>> sure if this "preferred zones"  should go into formatter/parsecontext.
>>
>> -Sherman



More information about the threeten-dev mailing list