Rules for numbers for which NumberInput.looksLikeValidNumber(String) returns true are a superset of JSON number, to roughly correspond to valid Java numbers (but more strict than say YAML).
The reason for this is that it is used by "Stringified numbers" functionality -- databind level functionality that takes JSON String (or XML, YAML, CSV etc for other backends) and coerces into valid Number. Given that different backends have different number validation rules this functionality needs to avoid being too strict.
Specific differences from JSON number so far includes:
Allow leading + sign (so +10.25 is valid unlike in JSON)
Allow omitting of leading 0 in front of . (so .00006 and -.025 are valid)
but one case that got accidentally stricter with 2.17 wrt "trailing" dot: values like 3. were previously allowed (in 2.16). So let's again allow this case.
Rules for numbers for which
NumberInput.looksLikeValidNumber(String)
returns true are a superset of JSON number, to roughly correspond to valid Java numbers (but more strict than say YAML). The reason for this is that it is used by "Stringified numbers" functionality -- databind level functionality that takes JSON String (or XML, YAML, CSV etc for other backends) and coerces into validNumber
. Given that different backends have different number validation rules this functionality needs to avoid being too strict.Specific differences from JSON number so far includes:
+
sign (so+10.25
is valid unlike in JSON)0
in front of.
(so.00006
and-.025
are valid)but one case that got accidentally stricter with 2.17 wrt "trailing" dot: values like
3.
were previously allowed (in 2.16). So let's again allow this case.