allthingssecurity opened a new pull request, #27988: URL: https://github.com/apache/camel/pull/27988
# Description [CAMEL-25703](https://issues.apache.org/jira/browse/CAMEL-25703) Since CAMEL-24168 the default `precision` of `@DataField` / `@KeyValuePairField` is `-1`, "to preserve the original scale from the input". Unmarshal keeps it, but marshal still rounds: for an unset precision `AbstractNumberFormat` leaves the `new DecimalFormat()` with its default pattern `#,##0.###`, which keeps at most three fraction digits (`HALF_EVEN`). So a `BigDecimal`, `Double` or `Float` field without `precision` and `pattern` is written with at most three decimals, silently: | field | value | written before this change | |---|---|---| | `BigDecimal` | `1.23456` | `1.235` | | `Double` | `12.3456789` | `12.346` | | `Double` | `0.000123` | `0` | A record that is unmarshalled and marshalled again therefore changes its numbers (CSV, fixed-length and key-value pair records all use these formats). The test added by CAMEL-24168 uses `10.35`, which has only two decimals. Change: - `AbstractNumberFormat`: without a precision (and without an implied decimal separator) the formatter keeps all fraction digits (`setMaximumFractionDigits(Integer.MAX_VALUE)`; `DecimalFormat` limits a `double` to 340 itself and prints its shortest decimal form). Whole numbers are still written without decimals (`10`), grouping and locale symbols are unchanged. - `FloatFormatFactory`: a finite `Float` with a fraction part and without precision is formatted from `Float.toString`, so `1.1f` stays `1.1` and does not become `1.100000023841858` through the widening to `double`. A whole-number `Float` keeps its exact digits as before (`123456792`, not the shorter `123456790` of `Float.toString`). - An explicit `precision`, a `pattern` or `impliedDecimalSeparator` work as before. What users can notice: such values are now written with all their decimals, also a `Double` that is the result of a calculation (`0.1 + 0.2` is written `0.30000000000000004`, before `0.3`). A note is added to the 4.24 upgrade guide; users who want a fixed number of decimals set `precision`. Tests: - New `BindyNumberWithoutPrecisionKeepsDecimalsTest` (5 tests, locale `en`): CSV marshal of `1.23456`, `0.000123`, `1.1f`; CSV unmarshal then marshal of `0.98765,12.3456789,2.5`; a fixed-length record unmarshalled and marshalled again; and two controls: `10`, `10.0` and `0.5f` are written as `10,10,0.5`, and the whole-number float `123456792f` as `123456792`. - Without the change (first four tests): 4 run, 3 failures (`but was: <1.235,0,1.1`, `<0.988,12.346,2.5`, `< 1.235 0`); the first control passes. The whole-number float control was added later and not run against main; main writes that float through the same `double` path, so it pins unchanged output. - With the change the camel-bindy tests pass: 243 run, 0 failures, 0 errors, 3 skipped (238 existing and the 5 new ones; the 3 skips are existing tests that were skipped before). What is not changed: the pattern formats (`DecimalFormat.parse` accepts a valid prefix of the text, a separate question), the `Integer` / `Long` formats, and the output of trailing zeros (`10.50` is written `10.5`, as before). What was not run: the full root build. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-25703](https://issues.apache.org/jira/browse/CAMEL-25703). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested camel-bindy, including the formatter and import-sort plugins. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
