reject hex-float and suffixed values in Converter.NUMBER

[rootvector2]

NUMBER routes any value containing . to Double.valueOf, which also accepts hexadecimal floating point (0x1.8p1), type suffixes (1.0d, 1.0f) and surrounding whitespace, so a strict BigDecimal parse now rejects those the way the integer branch already does.

Before you push a pull request, review this list:

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[garydgregory]

@rootvector2
Please see my question.

[garydgregory]

Why not just:

Suggested change

	new BigDecimal(s);
	return Double.valueOf(s);
	return new BigDecimal(s).doubleValue();

?

[rootvector2]

no reason, the second parse was redundant. switched to new BigDecimal(s).doubleValue() and pushed. only difference is -0.0 now parses as positive zero since BigDecimal has no signed zero, which doesn't matter here.

[garydgregory]

Please review the code you submit more thoroughly BEFORE you create a PR.

[rootvector2]

fair enough. the redundant parse should have been caught before opening this, I'll be more thorough.

[garydgregory]

Hello @rootvector2
Sorry to bring this up now but I want to step back here and look at the big picture... Why do we really want to do this? It seems like we would be now rejecting decimal formats that used to work. What is the advantage to CLI-based applications for this change?

[rootvector2]

the rejected forms are not really decimal formats, they are Java literal syntax leaking through Double.valueOf: hex float (0x1.8p1 parses to 3.0), the d/f type suffixes, and padded whitespace. every plain decimal and scientific value (3.14, -.5, 1.2e3) parses exactly as before, so nothing a user would type as a decimal changes. the advantage is consistent validation at the conversion boundary: the Long branch already rejects 0x10 and " 15 ", so today strictness depends on whether the value happens to contain a dot. that said, it is a behavior tightening, so if you would rather keep the leniency I am fine closing this.

[garydgregory]

Let's this one sit for now.

[rootvector2]

sure, no rush.

[garydgregory]

I converted this PR to a draft PR.