Bracket unresolved IPv6 host name in InetSocketAddress serialization

[renechoi]

InetSocketAddressSerializer writes host + ":" + port. When the address is resolved it takes the host part from InetAddress.toString() and brackets IPv6 literals, so a resolved address comes out as "[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443". When the address is unresolved there is no InetAddress at all, so it falls back to getHostName() and writes the literal bare:

InetSocketAddress.createUnresolved("2001:db8:85a3:8d3:1319:8a2e:370:7348", 443)
// serialized as "2001:db8:85a3:8d3:1319:8a2e:370:7348:443"

The trailing :443 is indistinguishable from another hextet, so the port is lost on the way back. This matters more since #5951, because deserialization now always produces unresolved addresses via InetSocketAddress.createUnresolved(), so an IPv6 value read by Jackson no longer survives a Jackson round-trip:

InetSocketAddress addr = MAPPER.readValue(q("2001:db8:85a3:8d3:1319:8a2e:370:7348"), InetSocketAddress.class);
String json = MAPPER.writeValueAsString(addr);   // "2001:db8:85a3:8d3:1319:8a2e:370:7348:0"
MAPPER.readValue(json, InetSocketAddress.class); // host name now ends with ":0"

I noticed it while reading the InetSocketAddress handling in JDKFromStringDeserializer after #6058/#5951, and JDKTypeSerializationTest.testInetSocketAddress() turned out to cover the unresolved form only for IPv4 and host names.

Fix: in the unresolved branch, bracket the host name when it is an IPv6 literal, matching what the resolved branch already does. Host names that are already bracketed (which is what the deserializer stores for "[...]:port" input) are left alone, so the value is never bracketed twice.

Verification (JDK 21, macOS):

• ./mvnw test -Dtest=JDKTypeSerializationTest#testInetSocketAddressUnresolvedIPv6 fails on 3.x without the InetSocketAddressSerializer change (expected: <"[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443"> but was: <"2001:db8:85a3:8d3:1319:8a2e:370:7348:443">) and passes with it.
• ./mvnw -B -ff -ntp verify: BUILD SUCCESS, Tests run: 6171, Failures: 0, Errors: 0, Skipped: 1.

The same code is on 2.x, and 2.x deserialization also creates unresolved addresses since #5951, so this likely belongs on an older line first. I opened it against 3.x since that is the default branch; I can open the equivalent PR against 2.x (or whichever line you prefer) so it merges forward normally.

[github-actions]

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	81.84%	📈 +0.000%
Branches	75.46%	📈 +0.030%

Coverage data generated from JaCoCo test results

[pjfanning]

Retargeting this to 2.18 branch would be great (oldest LTS). We require a CLA as described in https://github.com/FasterXML/jackson/blob/main/CONTRIBUTING.md#paperwork - could you provide a CLA based on this?

[renechoi]

Retargeted to 2.18.

The serializer is the same there, and _inetSocketAddress() on 2.18 also builds unresolved addresses through InetSocketAddress.createUnresolved() after #5951, so the round-trip problem reproduces unchanged on that branch. JDKTypeSerializationTest#testInetSocketAddressUnresolvedIPv6 fails on 2.18 without the serializer change:

expected: <"[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443">
 but was: <"2001:db8:85a3:8d3:1319:8a2e:370:7348:443">

and passes with it. Full suite on the retargeted branch (JDK 17, macOS): Tests run: 3453, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS.

The change is the same four lines in the unresolved branch plus the regression test, now against the 2.x package layout (com.fasterxml.jackson.databind.ser.std), so it should merge forward without conflicts.

On the CLA: understood, I am taking care of it and will send the signed copy to cla at fasterxml dot com.

[cowtowncoder]

@renechoi Any issues with CLA? No urgency, just wanted to follow up.

[gitar-bot]

CI failed: 1 build failure in OSS-Fuzz integration due to package namespace mismatch where fuzzers reference Jackson 3.x (`tools.jackson.databind`) while building the Jackson 2.18 branch (`com.fasterxml.jackson.databind`).

Overview

A single build failure occurred during OSS-Fuzz compilation where the fuzzer source files expect the Jackson 3.x package structure (tools.jackson.databind), but the PR targets the Jackson 2.18 branch which uses com.fasterxml.jackson.databind.

Failures

OSS-Fuzz Fuzzer Compilation Failure (confidence: high)

• Type: build
• Affected jobs: 93991524060
• Related to change: no
• Root cause: The OSS-Fuzz build script tries to compile fuzzers referencing tools.jackson.databind.*, but the jackson-databind 2.18 branch uses com.fasterxml.jackson.databind, causing javac errors (cannot find symbol / package does not exist).
• Suggested fix: Update the OSS-Fuzz configuration or fuzzers to match the package namespace of the 2.18 branch (com.fasterxml.jackson.databind).

Summary

• Change-related failures: 0
• Infrastructure/flaky failures: 1 (OSS-Fuzz build failure due to package namespace mismatch with branch 2.18)
• Recommended action: Update the external OSS-Fuzz project configuration for this repository to correctly align with Jackson 2.x package namespaces.

Code Review ✅ Approved

Brackets unresolved IPv6 host names during InetSocketAddress serialization to prevent port corruption on round-trip. No issues found.

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source}