On Mon, 16 Jun 2025 21:19:45 GMT, Johannes Graham wrote:
>> This PR replaces construction of intermediate strings to be parsed with more
>> direct manipulation of numbers. It also has a more streamlined mechanism of
>> handling `Long.MIN_VALUE` when parsing longs by using
>> `Long.parseUnsigne
> This PR replaces construction of intermediate strings to be parsed with more
> direct manipulation of numbers. It also has a more streamlined mechanism of
> handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>
> As a small side-effect it also eliminates the use of a
On Fri, 13 Jun 2025 19:34:40 GMT, Johannes Graham wrote:
>> Ah got it, I see your point. We would have goten underflow in
>> `ASCIIToBinaryConverter.doubleValue()` for some extreme cases without a
>> check.
>>
>> Is there a specific example you have that requires the switch to the newer
>> c
On Thu, 12 Jun 2025 22:52:21 GMT, Justin Lu wrote:
>> Unfortunately some check is required (a test fails), but I now realize what
>> I had was wrong. The issue is that on line 1084
>> (https://github.com/openjdk/jdk/pull/25644/files#diff-79e6fd549b5ec5e7f49658581beddcb07fcbb0c09ae8e1117c385b665
> This PR replaces construction of intermediate strings to be parsed with more
> direct manipulation of numbers. It also has a more streamlined mechanism of
> handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>
> As a small side-effect it also eliminates the use of a
On Thu, 12 Jun 2025 15:26:55 GMT, Johannes Graham wrote:
>> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1841:
>>
>>> 1839:
>>> 1840: static ASCIIToBinaryConverter readDoubleSignlessDigits(int
>>> decExp, char[] digits, int length) {
>>> 1841: if (decExp
On Wed, 11 Jun 2025 23:47:01 GMT, Justin Lu wrote:
>> Johannes Graham has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments
>
> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1841:
>
>> 1839:
> This PR replaces construction of intermediate strings to be parsed with more
> direct manipulation of numbers. It also has a more streamlined mechanism of
> handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>
> As a small side-effect it also eliminates the use of a
On Mon, 9 Jun 2025 23:44:20 GMT, Justin Lu wrote:
>> Johannes Graham has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> catch ArithmeticException
>
> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1848:
>
>> 1846:
On Tue, 10 Jun 2025 15:41:47 GMT, Johannes Graham wrote:
>> This PR replaces construction of intermediate strings to be parsed with more
>> direct manipulation of numbers. It also has a more streamlined mechanism of
>> handling `Long.MIN_VALUE` when parsing longs by using
>> `Long.parseUnsigne
On Mon, 9 Jun 2025 22:41:21 GMT, Johannes Graham wrote:
>> Sorry if I was unclear. I mean the `parse()` in the NumberFormat do not
>> throw NumberFormatException/ArithmeticException, but ParseException, so if
>> this piece of code need to throw something, it should be `ParseException`
>
> The `
> This PR replaces construction of intermediate strings to be parsed with more
> direct manipulation of numbers. It also has a more streamlined mechanism of
> handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>
> As a small side-effect it also eliminates the use of a
On Mon, 9 Jun 2025 22:46:50 GMT, Johannes Graham wrote:
>> This PR replaces construction of intermediate strings to be parsed with more
>> direct manipulation of numbers. It also has a more streamlined mechanism of
>> handling `Long.MIN_VALUE` when parsing longs by using
>> `Long.parseUnsigned
On Mon, 9 Jun 2025 22:08:08 GMT, Naoto Sato wrote:
>> Sorry, I'm not seeing where the original could throw ParseException.
>
> Sorry if I was unclear. I mean the `parse()` in the NumberFormat do not throw
> NumberFormatException/ArithmeticException, but ParseException, so if this
> piece of cod
> This PR replaces construction of intermediate strings to be parsed with more
> direct manipulation of numbers. It also has a more streamlined mechanism of
> handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>
> As a small side-effect it also eliminates the use of a
On Mon, 9 Jun 2025 22:03:37 GMT, Johannes Graham wrote:
>> The existing implementation does not throw
>> `NumberFormatException`/`ArithmeticException`, but `ParseException` if
>> parsing is failing. I would expect the same here.
>
> Sorry, I'm not seeing where the original could throw ParseExce
On Mon, 9 Jun 2025 21:45:12 GMT, Naoto Sato wrote:
>> I will leave this question to I18N reviewers, who are ultimately in charge
>> of DigitList.
>
> The existing implementation does not throw
> `NumberFormatException`/`ArithmeticException`, but `ParseException` if
> parsing is failing. I woul
On Thu, 5 Jun 2025 00:10:57 GMT, Chen Liang wrote:
>> This one is a little odd. The parse methods that call `getLong` are not
>> supposed to throw `NumberFormatException` either. So wherever `getLong` is
>> called, it must be preceded by a check to `fitsIntoLong`, which should avoid
>> any exc
This PR replaces construction of intermediate strings to be parsed with more
direct manipulation of numbers. It also has a more streamlined mechanism of
handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
As a small side-effect it also eliminates the use of a cached St
On Wed, 4 Jun 2025 23:59:38 GMT, Johannes Graham wrote:
>> src/java.base/share/classes/java/text/DigitList.java line 198:
>>
>>> 196: }
>>> 197: long pow10 = Math.powExact(10L, Math.max(0, decimalAt -
>>> count));
>>> 198: return Math.multiplyExact(v, pow10);
>>
>> Thes
On Wed, 4 Jun 2025 18:18:39 GMT, Johannes Graham wrote:
> This PR replaces construction of intermediate strings to be parsed with more
> direct manipulation of numbers. It also has a more streamlined mechanism of
> handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>
On Wed, 4 Jun 2025 23:15:37 GMT, Chen Liang wrote:
>> This PR replaces construction of intermediate strings to be parsed with more
>> direct manipulation of numbers. It also has a more streamlined mechanism of
>> handling `Long.MIN_VALUE` when parsing longs by using
>> `Long.parseUnsignedLong`
On Wed, 4 Jun 2025 18:18:39 GMT, Johannes Graham wrote:
> This PR replaces construction of intermediate strings to be parsed with more
> direct manipulation of numbers. It also has a more streamlined mechanism of
> handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>
23 matches
Mail list logo
