chore(sdk-java): align fastjson2 version to 2.0.65 - #12836

Independent Critical-only review — head de965367

A patch-level codec bump and the three places that name the version: runtime-broker/pom.xml 2.0.60 → 2.0.65, one sentence each in the JDBC design note (EN and zh-CN) and in the module README. 4 files, +4/-4, no code.

No historical blocker

The bot approved at this head, there are no inline comments and therefore no review threads, and nothing has ever been filed against this PR.

The alignment claim is true, and it removes a real resolution split

I checked every Java module's declaration at this head rather than trusting the description:

That last row is what makes this more than cosmetics. managed-agent-server embeds the broker but does not pin fastjson2, so before this change the version the broker actually ran against inside the server was whatever Maven's nearest-wins mediation picked from the surrounding modules — 2.0.65 from client/qwencode — while the broker's own build and tests ran 2.0.60. The module was therefore tested against one codec and shipped against another. Aligning the declaration removes that split; it does not introduce a new version anywhere.

The codec's documented invariants do not depend on the version being bumped

The broker's JSON use is narrow and its guarantees are structural rather than version-dependent, which is what I wanted to confirm before treating a codec bump as inert:

• Opaque Tool payloads disable fastjson2 reference detection explicitly, so $ref and @type stay data. That is a feature flag the code sets, not a default it inherits, so a default changing between 2.0.60 and 2.0.65 cannot reopen it.
• Finite BigDecimal values are written without exponent notation so a reader cannot narrow or overflow them as doubles, and scales above 2048 are rejected before persistence because the same codec cannot read them back. Both are writer- and guard-side, so nothing already stored depends on new reader behaviour, and a newer reader within the same 2.0.x line reading older output is the compatible direction.
• The exactNumber allow-list in HttpRuntimeTransport accepts only Integer, Long, BigInteger and BigDecimal and rejects everything else, then uses longValueExact(). Its fail-closed behaviour is a property of that allow-list, not of the codec, so no attestation path changes meaning with the bump.

The evidence that the round trips still hold is the strongest available here and it is green at this head: Runtime Broker and Managed Agent MariaDB / Java 21, Hosted no-tool processes / MySQL 8.4 / Java 21, Real daemon E2E / Java 11 and the whole Java matrix (ubuntu 11/17/21, windows, macos) all pass, which is the broker's repository contract and its JDBC paths running against real databases on the new codec. The author's local run reports 365 broker tests with 0 failures and 1 skipped (the optional real-worker test, which needs a bundle that was not supplied).

One stale version reference, explicitly not a finding

HttpRuntimeTransport.java:766 still justifies the allow-list's narrowness with "fastjson2 2.0.60 then reads 0.020000000000000000000E1 as 2" — a version this module no longer declares. This PR updates the three documentation sites and leaves that comment alone. It is a comment-accuracy item, so it is outside Critical-only scope and I am not filing it: no behaviour reads it, the allow-list fails closed whatever the codec does, and the sentence it appears in explains why an alternative (enabling exact-decimal reader features) was rejected, which stays a valid historical reason. Worth sweeping whenever that file is next touched, since a reader on 2.0.65 who re-tests the claim could otherwise conclude the allow-list is unnecessary.

CI

Every check passes at this head — the full Java matrix, both real-database lanes, Real daemon E2E, Test (ubuntu-latest, Node 22.x), Lint & Static, Integration Tests (no-AK, No Sandbox), web-shell E2E Smoke, both Desktop Shell lanes, triage, Classify PR, route, assign, label, authorize. Nothing is pending and nothing has failed.

Scope

I read the whole diff, verified the declared version in all four Java module poms at this head, and re-read the codec invariants the design note states against the code that implements them. I did not fetch the upstream 2.0.65 changelog or audit fastjson2 itself; my confidence that the round trips hold rests on the green real-database lanes, not on an independent reading of the codec.

Verdict: APPROVE — No Critical found and none was ever filed. All three modules that declare fastjson2 now declare the same version, which removes a mediation split where the broker was tested against 2.0.60 and embedded against 2.0.65; the codec's guarantees here come from explicit feature flags, writer-side formatting, a pre-persistence scale guard and a fail-closed allow-list rather than from version-specific behaviour; and every lane that round-trips JSON through a real database is green.