On 4/11/2021 12:14 am, Pavel Rappo wrote:
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
This PR follows up one of the recent PRs, where I used a non-canonical modifier
order. Since the problem was noticed [^1], why not to address it en masse?
As far as I remember, the first mass-canoni
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 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 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 Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi
wrote:
>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled
>> on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
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 Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it en
> masse?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
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 20:34:44 GMT, Martin Buchholz wrote:
>>> Pragmatically, fix the script to ignore those keywords on comment lines.
>>> Learn Perl, its just a regular expression pattern match and replace
>>> expression.
>>
>> I understand in principle how to modify that script to ignore doc c
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it en
> masse?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
28 matches
Mail list logo
