Evaluate options around supporting fast parser in TextNode class

[pjfanning]

Is your feature request related to a problem? Please describe.
Relates to FasterXML/jackson-core#577.

jackson-core and jackson-databind's StdDeserializer and NumberDeserializers check the StreamReadFeatures.
There are more classes that use NumberInput to parse floats/doubles - but that don't have access to the feature state to work out whether to use the fast parser. Examples include StdKeyDeserializer and TextNode.

[cowtowncoder]

One option is to call DeserializationContext.getParser() which should always return non-null parser instance.
In case of buffering (TokenBuffer) it seems, however, that feature flags are not copied from the "real" parser.

I guess one option would be to add another flag as a DeserializationFeature, assuming DeserializationContext (or DeserializationConfig that context delegates to) would be available. It should have same default as StreamReadFeature counterpart.
While it'd be bit confusing, at least that would allow users control over this setting.
Without this, I think we'd have to just use non-optimized (JDK) variant in cases where we cannot determine user's intent.

[cowtowncoder]

Not sure there's much need to support fast parser for TextNode tho, come to think of it -- as long as DoubleNode supports it.

Or is it common to serialize floating-point numbers as JSON Strings for some reason? Maybe thanks to Javascript or something?

[pjfanning]

@cowtowncoder TextNode method double asDouble(double defaultValue) is the one that needs to know if fast parser mode is needed. This may not be a major priority. It may be better to see if there is a demand for enhancing this method.

[cowtowncoder]

Right, I understand the route. Was more curious as to whether it is used by anyone -- it does explicit coercion from JSON String to double.

But I guess you noticed this by looking where parsing method was called, which makes sense wrt retrofitting code.