[nahapetyan-serob]

segmentio/encoding was added in #807 for one method: DontMatchCaseInsensitiveStructFields(). The json/v2 API does strict field-name matching natively, so the dependency isn't needed.

Behavior is unchanged. DefaultOptionsV1() keeps all v1 semantics — duplicate names permitted, invalid UTF-8 replaced, v1 null/merge handling, any-length arrays — and MatchCaseInsensitiveNames(false) overrides the one we don't want. No v2 strictness is adopted here. internal/json/json_test.go is untouched and passes as-is.

UnmarshalUseNumber stays on the v1 decoder and remains case-insensitive: no public API combines UseNumber with strict matching.

go-json-experiment/json hosts a mirror of encoding/json/v2 with the goexperiment.jsonv2 build tag (which is enabled by default on Go 1.27)

Breaking: go.mod goes 1.25.0 → 1.26 (the dependency declares it); Go 1.25 is no longer supported. CI matrix ["1.25","1.26"] → ["1.26","1.27"], which also covers both of the dependency's build paths.

[guglielmo-san]

why not using the Decoder also in this case? In this way the behavior is 100% not changed

[nahapetyan-serob]

Right. Will go back to using the Decoder.

[raveesh-me]

Hi @nahapetyan-serob, thanks for this. Dropping the segmentio dependency would be a nice simplification.

I noticed one interaction with a change that landed after this PR was opened, and wanted to flag it before it merges. Since #1401, jsonrpc2.DecodeMessage decodes every message envelope with internaljson.UnmarshalUseNumber, to keep large numeric IDs exact. In this PR, UnmarshalUseNumber moves to encoding/json's decoder, which matches field names case-insensitively. So with this branch merged into current main, the envelope is case-insensitive again, which is the behaviour #807 fixed (GHSA-wvj2-96wp-fq3f).

A minimal check, with this branch merged into main:

m, err := jsonrpc2.DecodeMessage([]byte(`{"jsonrpc":"2.0","id":1,"method":"tools/list","Method":"tools/call"}`))
// m.(*jsonrpc2.Request).Method is "tools/call"; on main it is "tools/list".

{"jsonrpc":"2.0","id":1,"METHOD":"tools/call"} is also accepted as a tools/call request; on main it isn't decoded as a request at all.

The merge is clean and the existing case-sensitivity tests only cover Unmarshal, so nothing currently catches it. Keeping UnmarshalUseNumber case-sensitive should be enough. #1454 (an unrelated allocation fix in the same file) adds TestUnmarshalUseNumberCaseSensitivity, which fails on this branch merged with main and would guard it whichever PR lands first.

On how the two PRs relate: #1454 keeps the current dependency and only changes how Unmarshal reads its input. With v2's decoder the per-call buffer is already small, so if this PR lands first, most of #1454's code change wouldn't be needed. I'd rebase it down to the tests.

[nahapetyan-serob]

Thanks @raveesh-me, good catch, confirmed. It's fixed on this branch:
UnmarshalUseNumber now uses the same case-sensitive v2 decoder as Unmarshal,
with a custom unmarshaler that keeps numbers in an any as encoding/json.Number.
I'm going to hold this PR until Go 1.28 is released. The minimum supported version
then becomes 1.27, which has encoding/json/v2 in the standard library, so we can
migrate to it directly instead of depending on go-json-experiment/json.
In the meantime I'll review #1454 for the buffer issue (#1453). This PR will be
rebased on top of it later, and your tests will carry over.