RFR: 8377427: Reduce substring allocations in Color.web(String, double) [v10]

[Michael Strauß]

On Fri, 20 Feb 2026 23:26:12 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> In contrast to a `long` literal, a `double` literal can have any number of digits. The value of the literal is then determined by the IEEE-754 round-to-nearest and ties-to-even rule (like in this algorithm). This is why the literal `0.19999999999999998335` has a value of 0.19999999999999998 (the nearest representable value). For comparison, the literal `0.19999999999999997` also has the value 0.19999999999999998.
>
> Right, but we are not testing a double literal.  We are testing the equivalence to `Double.parseDouble()`, correct?

In this specific test: `assertSameDouble(0.19999999999999998335, "0.19999999999999998335")`
we find that:
1. The Java compiler interprets the literal (first argument) as 0.19999999999999998
2. Both `Double.parseDouble()` and `CssNumberParser.parseDouble()` return the value 0.19999999999999998.

So everyone agrees. In fact, everyone agrees for _all_ numbers where the significand can fit into 64 bits. For numbers with more digits than can fit in 64 bits, there is a difference:
1. The Java compiler and `Double.parseDouble()` convert with infinite precision, and then round to the nearest representable double.
2. CssNumberParser truncates to 64 bits, and then rounds to the nearest representable double. This almost always results in the same value, but I think there can be cases very close to the midpoint between two adjacent doubles that the result can be different by one ulp.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/2069#discussion_r2835523034