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

[Andy Goryachev]

On Fri, 13 Feb 2026 20:53:53 GMT, Michael Strauß <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/CssNumberParser.java line 46:
>> 
>>> 44:      * This implementation is allocation-free and avoids per-digit floating-point math by accumulating
>>> 45:      * a (truncated) base-10 significand and a base-10 exponent. It does not aim for "perfectly rounded"
>>> 46:      * conversion for extremely long representations, but generally returns values within 2 ULPs of the
>> 
>> what is the source of error in this case?  would it make sense to explain (even though it's not a public class)?
>
> Double parsing can be lossy if you think of the input as an _exact_ number. Some algorithms parse an exact number into the nearest representable double by (conceptually) first converting the number with infinite precision, and then rounding to the nearest double. `Double.parseDouble()` does that, while the simpler algorithm in this PR doesn't. It's not like one algorithm is exact and the other isn't, it's more like this algorithm sometimes won't give you the nearest representable double, but be off by an ulp. `Double.parseDouble()` will always give you the nearest representable double.

perhaps a short version of this explanation should be added to the javadoc, to explain the behavior (especially since it differs from `Double.parseDouble()`.

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

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