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

[Michael Strauß]

On Sat, 21 Feb 2026 00:34:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> 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.
>
> thank you for clarifications!  that's why I want to test the adjacent values (+/- N ulps).
> 
> I'll try to come up with some additional tests next week.

I've changed the implementation slightly to fall back to `Double.parseDouble()` for values that don't fit into 64 bits. This means that `CssNumberParser` now always returns the same value as `Double.parseDouble()`.

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

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