FastDoubleParser doesn't support all input formats as the default OpenJDK Float/Double parsers

[grcevski]

The FastDoubleParser recently introduced through this issue #577 is 3-4x times faster compared to the version that's implemented in OpenJDK. However the OpenJDK Double/Float parsers support variety of input formats that the FastDoubleParser will fail on, therefore it can cause unexpected regressions when used.

For example, the FastDoubleParser will fail with a NumberFormatException on these example patterns (there are many more to be found in the OpenJDK Double/Float tests):

1.1e-23f
0x.003p12f
0x1.17742db862a4P-1d

[grcevski]

I made a PR with a proposed fix to use the default Java parses as a fallback when the exception occurs #779

[grcevski]

I opened an issue with FastDoubleParser here wrandelshofer/FastDoubleParser#19

[cowtowncoder]

@grcevski Those are not valid JSON floating-point numbers so shouldn't they fail? There are cases where databind is more liberal in what it accepts, although those cases are not well-defined.

[grcevski]

Yeah it seems so, I didn't realize initially that the failures were explicitly related to the type suffix in particular. I don't think it will cause issues with JSON specifically (nor with XML), I'm not sure with other parsers implemented on top of jackson-core. The PR I opened has a bit more discussion on this.

[cowtowncoder]

@grcevski Right, I think that ticket against FDP makes complete sense. Since Jackson backend decoders/parsers validate input anyway more lenient parsing by FDP should not be problematic either. Jackson JSON decoder does have some options for more lenient parsing too (allow optional leading plus sign, make leading 0 optional etc) so there may be some complications but overall I think things should be fine.

[grcevski]

Closing this since it's only an issue with trailing 'f' and 'd' suffixes.