Encode setBody(String) bodies with String.getBytes - #2371

Summary

• setBody(String) request bodies are now encoded with body.getBytes(charset) instead of charset.encode(CharBuffer.wrap(body)).
• The bytes sent are the same as before. Encoding is 3 to 20 times faster for ASCII and Latin-1 text.
• Form params, digest hashing and HTTP/2-specific code are unchanged.

Problem

CharBuffer.wrap(String) returns a buffer with no backing array. The JDK encoder therefore takes its per-char buffer loop (virtual get/put with bounds checks), not the array loop or the String.getBytes ASCII/Latin-1 fast paths. CharsetEncoder.encode also starts at 1.1 bytes per char and grows by copying. This runs once per request attempt, on the caller thread, and costs O(body length).

Change

NettyRequestFactory.body(...) builds a NettyByteArrayBody from getBytes(charset). Before, it built a NettyByteBufferBody around the encoded ByteBuffer. Both are NettyDirectBody: same content length, unpooled heap ByteBuf, no content-type override. The HTTP/1.1 and HTTP/2 paths and replays read the body from the DefaultFullHttpRequest content, so they behave the same.

Both APIs replace malformed and unmappable input with the charset's default replacement. NettyRequestFactoryStringBodyTest checks byte-for-byte equality through newNettyRequest for every charset the JDK can encode, with unpaired surrogates, BOM and replacement chars, and UTF-16/UTF-32 (BOM writing). The same sweep in a standalone check on JDK 17, 21 and 25 showed 0 differences.

Netty's ByteBufUtil.writeUtf8 with an exact-size array was also tried and rejected: for a high surrogate followed by a valid pair it emits ??? where the JDK emits ? plus the pair.

HttpUtils.urlEncodeFormParams is left alone. It encodes a pooled StringBuilder, not a String, so getBytes would need an extra toString().

Benchmark

StringBodyEncodeBenchmark (new), JDK 17, UTF-8, -f 2 -wi 3 -i 5 -prof gc. Length is in chars. mixed is ASCII JSON ending in one emoji, so the String is stored as UTF-16.

Trade-off: for a String stored as UTF-16 (any char above U+00FF), getBytes(UTF_8) encodes into a scratch array of 3 bytes per char and then trims it. Transient allocation therefore grows for that text (same on JDK 21 and 25). Encoding is still faster, and the body kept for the request is exact-size; before, it was the encoder's oversized buffer.

The host was shared with other builds, so take the timings as indicative. B/op is deterministic.

AI disclosure

Claude Code on behalf of Pavel Ptashyts. The commit includes Co-Authored-By per AGENTS.md.

Test plan

• NettyRequestFactoryStringBodyTest: 4 tests pass.
• mvnw.cmd -B -ntp -Dgpg.skip=true clean verify on JDK 17 (no JDK 11 was available on the host): 1,861 tests, 0 failures, 0 errors, 35 skipped; Revapi passed. Source/target is 11. JDK 11 coverage comes from CI.

🤖 Generated with Claude Code