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

[Michael Strauß]

On Tue, 17 Feb 2026 20:00:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The code is not copied, it's an implementation of the algorithm presented in the referenced paper. The algorithm is what I would call state of the art, it's used in several standard libraries:
>> 1. [Go since v1.16](https://go.dev/doc/go1.16#strconvpkgstrconv)
>> 2. [Rust since v1.55](https://blog.rust-lang.org/2021/09/09/Rust-1.55.0/#faster-more-correct-float-parsing)
>> 3. [GNU libstdc++](https://gcc.gnu.org/pipermail/libstdc%2B%2B-cvs/2022q1/037428.html)
>> 4. [LLVM libc](https://libc.llvm.org/configure.html) has a toggle for it
>> 
>> The problem with `Double.parseDouble()` is not that it's slow, or mainly that it requires substring allocation (although that's unfortunate), it's that it parses a Java-specific number grammar, where it should be parsing CSS numbers.
>> 
>> The purpose of code review also can't be to demonstrate that Lemire's algorithm is indistinguishable from the JDK's algorithm. How would you even do that? I certainly can't prove that mathematically, and enumerating all doubles is impossible. If this algorithm produces correctly-rounded doubles, then it must be equivalent to the JDK algorithm. As I said, the algorithm is state of the art, and people more knowledgeable than I have obviously concluded that it's correct, so I think we can leave it at that.
>> 
>> What remains is to verify that the _implementation_ of the algorithm is correct, and from all the testing I haven't found a single example that would be different from the JDK algorithm.
>
>> What remains is to verify that the implementation of the algorithm is correct
> 
> exactly, thanks for correcting.  how do we do that?
> 
>> The problem with Double.parseDouble() is not that it's slow, or mainly that it requires substring allocation
> 
> I agree!  my comment still stands - this is something we should ask the JDK, maybe to provide a `Double.parseDouble(CharSequence, int start, int end)`.  This does not preclude us from providing an implementation in the mean time.
> 
>> it's an implementation of the algorithm presented in the referenced paper. 
> 
> so you are the author, correct?
> 
> We still need to review the implementation.  The recent changes made it more complex than earlier, so

I'm the author of the implementation. Asking for another overload of `Double.parseDouble(CharSequence, int, int)` doesn't change the fact that this is parsing a Java-specific number grammar.

Usually, we require three reviewers for enhancements that significantly change FX, are particularly high risk, or that have a large API surface. This is neither of these cases (it's just color parsing so far), so I think two reviewers is still sufficient. I also think that normal review standards should apply here (and these are significantly lower that what you'd do if you changed `Double.parseDouble()`).

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

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