Lock and characterize Avro VarHandle float/double decoding behavior

[jaipilot]

Before

The PR under evaluation (mirroring upstream jackson-dataformats-binary#762) adds AvroVarHandleUtil and wires it into JacksonAvroParserImpl.decodeFloat()/decodeDouble() to read little-endian IEEE-754 bytes via a single VarHandle access instead of 4/8 sequential byte-shift-and-mask operations, with a byte-shifting fallback for runtimes lacking VarHandle. The only existing coverage (AvroNumberTest.testNumberCoercions) exercised a single float (0.125f) and double (-3.75) value.

Changes in this companion

• Added AvroVarHandleUtilTest (new package tools.jackson.dataformat.avro.deser test class) directly characterizing getIntLE/getLongLE's little-endian byte layout: zero, positive, negative/sign-bit values, and non-zero offsets.
• Added AvroNumberTest.testFloatEdgeCasesRoundTrip/testDoubleEdgeCasesRoundTrip, round-tripping IEEE-754 boundary values (+-0, +-1, MIN_VALUE/MAX_VALUE/MIN_NORMAL, NaN, +-Infinity, typical fractions) through the real Avro writer/reader, from both a plain byte array and a LimitingInputStream that forces the buffer-refill (_loadToHaveAtLeast) code path used mid-stream by decodeFloat/decodeDouble. Verified bit-exact via floatToRawIntBits/doubleToRawLongBits.
• Added the corresponding opens tools.jackson.dataformat.avro.deser; line to avro/src/test/java/module-info.java, required for the new test class to run under the project's JPMS test module.
• Removed one stray duplicate blank line left by the PR after JacksonAvroParserImpl._checkVarHandleAvailable(), matching the single-blank-line convention used at the identical spot in the sibling SmileParserBase.

Behavior preservation

All 13 focused tests (4 in AvroNumberTest, 9 in AvroVarHandleUtilTest) pass identically before and after the production whitespace edit, using the exact same command. The full avro module test suite and the complete multi-module ./mvnw clean install both pass.

Performance

A standalone microbenchmark (5 runs each, JDK 21) confirms the PR's own optimization is real: AvroVarHandleUtil reads run faster than the byte-shifting fallback it guards (int: median 74.76ms vs 88.20ms per 20M reads; long: median 83.23ms vs 141.03ms). No further production change was made -- see the performance pass detail for what was considered and rejected.

Limitations

• Modernization pass is not applicable: neither changed file pins a JDK/dependency/build version.
• The microbenchmark is a simple nanoTime loop over a synthetic workload, not a full decode benchmark; it is offered only as confirming evidence for the PR's already-shipped choice, not as a new performance claim.
• The byte-shifting fallback branch (for runtimes without VarHandle) is exercised only indirectly through this evidence, not through an actual non-VarHandle JVM, consistent with how the analogous Smile/CBOR utilities are covered in this repository.

---

Generated by JAIPilot Cloud for #1 from Anthropic session sesn_01DuzYQtLUhVzKRiEUHwAXb1.