RFR: 8377427: Reduce substring allocations in Color.web(String, double) [v10]
Michael Strauß
mstrauss at openjdk.org
Fri Feb 20 01:01:59 UTC 2026
On Thu, 19 Feb 2026 21:13:40 GMT, Markus Mack <mmack at openjdk.org> wrote:
>> I also want this to be well-tested, but I want the tests to be meaningful and add significant test coverage, that is, each test should be testing something unique. I don't see anything that's unique in either testing values close to randomly selected numbers, nor in the bit patterns you suggest (there's nothing special about those bit patterns, they are as good as any other pattern). I already have tests for normal values, subnormal values, and significant limits (including rounding above and below). I'm not going to add more of the same, unless it's clear that a specific _kind_ of test is missing.
>
> Here are some test cases that may be worth including, because they relate to different code paths, or might break in case some of the rounding rules aren't implemented correctly. They come directly from examples in the algorithm's original paper. Rounding in the code is done exactly as prescribed in the algorithm everywhere I checked.
>
> assertSameDouble(0.2, "0.2");
> assertSameDouble(0.2, "0.20000000000000001110");
> assertSameDouble(0.19999999999999998335, "0.19999999999999998335");
> assertSameDouble(9000000000000000., "9000000000000000.5");
> assertSameDouble(9000000000000002., "9000000000000001.5");
> assertSameDouble(9000000000000002., "9000000000000002.5");
> assertSameDouble(1e22, "1e22");
> assertSameDouble(1e23, "1e23");
> assertSameDouble(7450580596923828125e-27, "7450580596923828125e-27");
> assertSameDouble(2440254496e57, "2440254496e57");
> assertSameDouble(9007199254740993., "9007199254740993");
> assertSameDouble(9.109e-31, "9.109e-31");
>
> Testing indicates all but the third one work. There, the algorithm isn't even used, though.
I've added these tests. The reason why `assertSameDouble(0.19999999999999998335, "0.19999999999999998335")` fails is because there are more digits in the number than fit in a `long`, and thus the actual number being parsed is truncated.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2830869746
More information about the openjfx-dev
mailing list