Skip to content

Fix #6065: APPLY_JSON_INCLUDE_FOR_CONTAINERS does not fully remove empty collection#6070

Open
seonwooj0810 wants to merge 1 commit into
FasterXML:3.xfrom
seonwooj0810:fix/issue-6065-container-include-empty-collection
Open

Fix #6065: APPLY_JSON_INCLUDE_FOR_CONTAINERS does not fully remove empty collection#6070
seonwooj0810 wants to merge 1 commit into
FasterXML:3.xfrom
seonwooj0810:fix/issue-6065-container-include-empty-collection

Conversation

@seonwooj0810

Copy link
Copy Markdown
Contributor

Fixes #6065

Root cause

Content-level @JsonInclude filtering for containers (added in #5369) suppresses empty/null elements during serialization, but the collection serializers' isEmpty() only consulted the raw Collection.isEmpty(). As a result a collection that is non-empty by size but becomes empty once content filtering is applied — e.g. a List holding only nulls (or only empty Strings) under content = NON_EMPTY — was still emitted as [] and therefore not dropped by the enclosing property's value-level NON_EMPTY. The equivalent Map was already dropped because MapSerializer.isEmpty() recurses into its values (#1649), producing the inconsistency reported here.

Change

Make isEmpty() content-aware for the collection serializers, mirroring MapSerializer:

  • CollectionSerializer, IndexedListSerializer — reuse a new shared helper AsArraySerializerBase#_allElementsSuppressed(...) that walks elements and reports the container empty when every element would be suppressed (reusing the existing dynamic element-serializer resolution).
  • StaticListSerializerBase (String collections) — equivalent inline check for the natural-type element path.

The new logic is gated on the existing _needToCheckFiltering(ctxt) guard (APPLY_JSON_INCLUDE_FOR_CONTAINERS enabled and content suppression configured), so behavior with the feature disabled — the default — is unchanged.

Verification

Added JsonIncludeContainerEmpty6065Test (the reporter's cases plus object lists, sets, retained-content and feature-disabled guards). The 4 content-empty assertions fail on 3.x before the change and pass after; the retained-content / feature-off assertions pass both ways. Existing JsonIncludeCollectionTest, JsonIncludeArrayTest, MapInclusionTest and the full ser.filter suite (133 tests) remain green.

Verification done: (1) searched open PRs/timeline — no in-flight PR; (2) no self-claim in thread; (3) fix is in .java serializers; (4) reproduced the bug on latest upstream/3.x with a failing test; (5) confirmed the value/content-inclusion mechanism vs. the Map path (#1649/#5369).

…remove empty collection

Content-level `@JsonInclude` filtering (added for containers in FasterXML#5369) suppresses
empty/null elements at serialization time, but the collection serializers'
`isEmpty()` only checked the raw `Collection.isEmpty()`. So a collection that
becomes empty *after* content filtering (e.g. a `List` holding only nulls under
`content = NON_EMPTY`) was still emitted as `[]` and not dropped by value-level
`NON_EMPTY`, whereas the equivalent `Map` was correctly dropped (FasterXML#1649).

Make `isEmpty()` content-aware for `CollectionSerializer`, `IndexedListSerializer`
and `StaticListSerializerBase`, mirroring `MapSerializer`: when
`APPLY_JSON_INCLUDE_FOR_CONTAINERS` is enabled and content suppression is
configured, a container whose every element would be suppressed is reported as
empty. Gated on `_needToCheckFiltering`, so default behavior is unchanged.
@github-actions

github-actions Bot commented Jul 3, 2026

Copy link
Copy Markdown

🧪 Code Coverage Report

Metric Coverage Change
Instructions coverage 81.71% 📈 +0.000%
Branches branches 75.15% 📈 +0.000%

Coverage data generated from JaCoCo test results

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SerializationFeature.APPLY_JSON_INCLUDE_FOR_CONTAINERS does not fully remove empty collection during serialization

1 participant