Drop FastDoubleParser from Jackson 3.0? (to avoid shading, if no significant speed up)

[cowtowncoder]

Due to major hurdles with #1381, it'd be good to avoid Shading altogether.

Now: I think FastDoubleParser gives major speedup on JDK 8, but not sure how much with JDK 17 or 21 and later. If benefit is not great, it may make sense to drop the dependency.

@pjfanning I think you did some measurements? Or was that with serialization ("Schubfach")?

[cowtowncoder]

Hmmh. Ok, I think it's just FP write that has improved significantly with later JDKs, as per:

https://medium.com/@cowtowncoder/jackson-2-18-fast-vector-reads-writes-6c2cf99c4594

(that I wrote myself not that long ago )

Reads are still much faster.

[pjfanning]

FastDoubleParser still has a big edge over in-built Java conversions according to https://github.com/wrandelshofer/FastDoubleParser. Schubfach for writes (as opposed to parsing) has been built into one of the recent Java Runtimes - but I don't think that includes Java 17.

What if we made FastDoubleParser an optional dependency? Then we wouldn't need to shade the jar. We could document that users who enable the fast parser configs have to explicitly add the dependency to fastdoubleparser jar?

[cowtowncoder]

Ok, let's keep it. May consider not-shading it but... that'd be another dependency. Need to think.

[cowtowncoder]

@pjfanning I think I was able to make things work with shading (see #1381 for details), after all.
So we are ok, fortunately.

My hesitation in making it optional has to do with jackson-core being a very low-level component; for proper modules it'd be less of a concern.
There are multiple ways to make things optional but unfortunately many rely on dynamic loading which is getting more and more difficult partially thanks to JPMS (but not just that(.