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 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:
+sign (so+10.25is valid unlike in JSON)0in front of.(so.00006and-.025are 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.