Skip null check in doMarshal JSON serializer

[RanVaknin]

Background

During JSON serialization, JsonProtocolMarshaller.doMarshall() iterates every SdkField on a POJO and calls marshallField() for each one, including fields that are null. marshallField uses a registry to dispatch to a type specific marshaller (string, int, map, null, etc ) based on the field's value.
When the value is null, it dispatches to the NULL marshaller, that checks if the field is required (throw) or not (no-op). For non-required null fields, this entire chain (registry lookup, marshaller resolution, trait check) is wasted work.

The proposed change is to short circuit null handling for payload fields directly on the generic doMarshall() layer, and avoid the dispatch. Non payload fields still delegate to marshallField since their null marshallers have different validation logic.

Boto3's RestJson serializer handles it very similarly.

Testing

Our protocol tests already cover the main code paths of doMarshal (null headers, null query params, partial payload serialization). I added one unit test to specific JsonProtocolMarshaller directly to cover the case where a null required payload field reaches the marshaller. This codepath is caught earlier by the SDK's generated validators, but the this is just make sure the marshaller handles it correctly if that layer is ever bypassed.

Results:

Benchmarks written in #6776

Before:

After

Protocol	Operation	Master (ops/µs)	Feature (ops/µs)	Improvement
RestJson	CreateFunction deser	0.176	0.175	-0.57%
RestJson	CreateFunction ser	0.284	0.327	15.14%
JSON	DynamoDB PutItem deser	0.141	0.141	0.00%
JSON	DynamoDB PutItem ser	0.101	0.124	22.77%
CBOR	CloudWatch GetMetricData deser	0.382	0.385	0.79%
CBOR	CloudWatch GetMetricData ser	0.416	0.457	9.86%

[RanVaknin]

Almost all of the codepaths that this file tests are covered by the protocol test package. nullPayloadField_required_throwsIllegalArgumentException is the only test that is not covered by the end to end tests because its technically not possible to get there. This codepath branch was likely added as a defense in depth.

[alextwoods]

Do we validate required client side? I thought we generally didn't do client side validation of required and instead just sent these requests to the service (since the api may have evolved and removed the required over time).

[RanVaknin]

I agree, but this is not a new validation. I had to port this logic out from the null marshaller:

https://github.com/aws/aws-sdk-java-v2/blob/master/core/protocols/aws-json-protocol/src/main/java/software/amazon/awssdk/protocols/json/internal/marshall/SimpleTypeJsonMarshaller.java#L42

since we are handling nulls now at the doMarshal level.

[alextwoods]

Ah I see - yeah, agree this makes sense here then.

[alextwoods]

Overall looks good. Needs a changelog I think.

[sonarqubecloud]

Quality Gate failed

Failed conditions
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[github-actions]

This pull request has been closed and the conversation has been locked. Comments on closed PRs are hard for our team to see. If you need more assistance, please open a new issue that references this one.