<i18n dev> RFR: 8300818: Reduce complexity of padding with DateTimeFormatter [v2]

Roger Riggs rriggs at openjdk.org
Wed Apr 12 17:44:38 UTC 2023


On Fri, 24 Mar 2023 19:28:57 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Meant that you should verify that something like this, which just add a little padding, doesn't regress with your changes: 
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>     .appendLiteral("Year:")
>>     .padNext(5)
>>     .appendValue(ChronoField.YEAR)
>>     .toFormatter();
>> ... 
>> dtf.format(LocalDateTime.now());
>> 
>> And similar for effectively no padding (`.padNext(4)` in the above example). As this API might often be used to ensure short 2-4 char fields are correctly padded I think it's important that we're not adding overhead to such use cases.
>
> Added benchmark for this

Special casing for len == 0 and keeping the existing buf.insert for len == 1 would avoid object creation except when it would improve performance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1164453452


More information about the i18n-dev mailing list