On Wed, 3 Nov 2021 22:55:23 GMT, Claes Redestad wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove accidentally committed experimental @Stable (no effect on micros)
>
> Thanks, Naoto!
@cl4es For `DateTimeFor
On Wed, 3 Nov 2021 21:57:44 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having l
On Wed, 3 Nov 2021 21:57:44 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having l
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When printing
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When printing
On Wed, 3 Nov 2021 19:44:35 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having l
On Wed, 3 Nov 2021 18:17:38 GMT, Naoto Sato wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Minor cleanup
>
> test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.java line
> 80:
>
>> 78:
>> 79:
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When printing
On Wed, 3 Nov 2021 17:23:51 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having l
On Wed, 3 Nov 2021 17:33:36 GMT, Naoto Sato wrote:
> Looks good. I'd create a new test case class out of
> `TestFractionPrinterParser`, as you introduced the new `NanosPrinterParser`.
It was only indirectly a test of `FractionPrinterParser`; it's really a test of
`PrinterParsers` built using `
On Wed, 3 Nov 2021 17:23:51 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having l
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When printing
On Wed, 3 Nov 2021 14:24:28 GMT, Stephen Colebourne
wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add test verifying OOB values throw exception
>
> Thanks for adding the new tests, and finding that fraction fo
On Wed, 3 Nov 2021 13:14:42 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having l
On Wed, 3 Nov 2021 12:17:09 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> line 3544:
>>
>>> 3542: BigDecimal valueBD =
>>> BigDecimal.valueOf(value).subtract(minBD);
>>> 3543: BigDecimal fraction = valueBD.di
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When printing
On Wed, 3 Nov 2021 12:44:39 GMT, Claes Redestad wrote:
>> I'll see to it.
>
> When adding a test for this I discovered that
> `FractionPrinterParser::format` will end up calling
> `field.range().checkValidValue(value, field)`
> [here](https://github.com/openjdk/jdk/blob/579b2c017f24f2266abefd
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When printing
On Wed, 3 Nov 2021 12:21:00 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> line 3266:
>>
>>> 3264: if (!field.range().isValidIntValue(value)) {
>>> 3265: if (fallback == null) {
>>> 3266:
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When printing
On Wed, 3 Nov 2021 11:53:52 GMT, Stephen Colebourne
wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add fallback for values outside the allowable range
>
> src/java.base/share/classes/java/time/format/DateTimeFo
On Wed, 3 Nov 2021 12:04:10 GMT, Stephen Colebourne
wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add fallback for values outside the allowable range
>
> src/java.base/share/classes/java/time/format/DateTimeFo
On Tue, 2 Nov 2021 11:03:02 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having l
On Tue, 2 Nov 2021 07:31:09 GMT, Stephen Colebourne
wrote:
>> I see what you're saying that an arbitrary `Temporal` could define its own
>> fields with its own ranges, but I would consider it a design bug if such an
>> implementation at a whim redefines the value ranges of well-defined
>> con
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When printing
On Mon, 1 Nov 2021 22:35:58 GMT, Claes Redestad wrote:
>> The commentary on this line could probably be improved, but this is in a
>> private printer-parser that will only be used for NANO_OF_SECOND and not any
>> arbitrary `TemporalField` (see line 704), thus I fail to see how this
>> assumpt
On Mon, 1 Nov 2021 22:27:08 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> line 3269:
>>
>>> 3267: return false;
>>> 3268: }
>>> 3269: int val = value.intValue(); // NANO_OF_SECOND must fit in
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When printing
On Mon, 1 Nov 2021 22:18:52 GMT, Stephen Colebourne
wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> hav
On Mon, 1 Nov 2021 13:04:20 GMT, Claes Redestad wrote:
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looke
On Mon, 1 Nov 2021 13:04:20 GMT, Claes Redestad wrote:
> Prompted by a request from Volkan Yazıcı I took a look at why
> DataTimeFormatters are much less efficient for some common patterns than
> custom formatters in apache-commons and log4j. This patch address some of
> that gap, without havi
Prompted by a request from Volkan Yazıcı I took a look at why
DataTimeFormatters are much less efficient for some common patterns than custom
formatters in apache-commons and log4j. This patch address some of that gap,
without having looked at the third party implementations.
When printing tim
32 matches
Mail list logo
