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

[Andy Goryachev]

On Fri, 20 Feb 2026 23:48:25 GMT, Michael Strauß <mstrauss at openjdk.org> wrote:

>> 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.

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.

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

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