[NUAAwqy]

Why?

Float16.toBits(3.0e-8f) currently returns 0x0000. Every float strictly between 2^-25 and 2^-24 is above the midpoint between zero and the smallest float16 subnormal, so round-to-nearest-even — the rounding rule the project documents for float16 — must place it at 0x0001. Instead the conversion's flush-to-zero guard fires one binade too early and drops the whole interval to signed zero. Measured over the whole input space: 16,777,214 of the 2^32 float32 bit patterns are wrong (the entire 2^-25 binade, both signs) — e.g. toBits(4.4702e-8f) → 0x0000 instead of 0x0001, toBits(-3.0e-8f) → 0x8000 instead of 0x8001.

What does this PR do?

floatToFloat16Bits shifts the 24-bit float significand onto the subnormal grid and rounds with a round/sticky correction. The netShift >= 24 shortcut declares any shift of 24 a guaranteed flush, but at netShift == 24 the correction still has work to do: the exact tie 2^-25 rounds down to zero (unchanged behaviour, and correct under ties-to-even), while anything above it rounds up to MIN_VALUE. The guard becomes netShift > 24, which also keeps the very large shifts — where the round/sticky indexing would wrap on Java's masked shift counts — inside the flush branch. Decode (toFloat) is untouched.

Evidence

• Exhaustive differential sweep against java.lang.Float.floatToFloat16 (JDK 20+) over all 2^32 float32 inputs: 16,777,214 disagreements before the fix — all of them this flush, both signs, every pattern of the 2^-25 binade except the exact 2^-25 tie — and 0 after. NaN payload canonicalisation differs from the JDK in 32,766 patterns before and after alike (sNaN → qNaN), so NaN behaviour is untouched.
• Float16Test gains two tests: a boundary test (the 0x33000000 tie and the largest float below it stay zero; 0x33000001, 3.0e-8f, 4.4702e-8f, 0x337FFFFF, negatives and parse("3e-8") all give 0x0001/0x8001) and a sweep over all 2^23−1 mantissas of the 2^-25 binade for both signs asserting zero flushes. Red run: 2 failures; green run: 0.
• Full fory-core module: 2348 tests, 1 failure — ExpressionTest.testLiteralSourceRoundTrip, which reproduces on pristine 8e93633 with this change reverted (pre-existing, unrelated package).
• Style: mvn -pl fory-core spotless:check and checkstyle:check pass (spotless run under JDK 21, per .agents/languages/java.md).
• The new tests are Java 8-clean on purpose — hardcoded bit patterns only, no Float.floatToFloat16 — so the JDK 8/11/17/21/25/26 CI matrix is safe.
• Existing ASF license headers preserved; no new files.

User-facing change?

No public API or binary-protocol change: values that used to serialize as zero now serialize as the subnormal they should have been. Existing float16 payloads are unaffected because no float16 encoding decodes into that interval, so the xlang round-trip suites and docs/specification/** are unaffected — this is a Java-only rounding bug in a value range no other encoding produces.

AI Usage Disclosure

• substantial_ai_assistance: yes
• scope: code drafting (fix), tests, PR body drafting
• affected_files_or_subsystems: java/fory-core/src/main/java/org/apache/fory/type/Float16.java, java/fory-core/src/test/java/org/apache/fory/type/Float16Test.java
• ai_review: line-by-line self-review completed (each hunk checked against the IEEE-754 binary16 rounding rules; red→green confirmed). The §5 two-reviewer AI review loop with persisted artifacts has not been attached yet; it can be run and linked before maintainer review on request.
• ai_review_artifacts: none persisted yet (see previous line)
• human_verification: mvn -pl fory-core -am test -Dtest=Float16Test red (2 failures) → green (0); full module 2348 tests / 1 pre-existing failure reproduced on the base commit; exhaustive 2^32 differential sweep 16,777,214 → 0; spotless/checkstyle clean
• performance_verification: N/A — one comparison widened on a value-conversion path; no serialization hot-path, allocation or wire-format change
• provenance_license_confirmation: original work under Apache-2.0; no third-party code introduced; license headers preserved