Prevent use of unsupported `@JsonManagedReference`/`@JsonBackReference` for Record-valued properties

[JBodkin-Amphora]

Is your feature request related to a problem? Please describe.

Currently, it isn't possible to use records with JsonManagedReference/JsonBackReference as records do not have a mutator available. Would it be possible to support this?

Describe the solution you'd like

Ability to use the existing annotations

Usage example

public class RecordTest {

    public static void main(String[] args) throws Exception {
        final var objectMapper = new ObjectMapper();
        final var json = "{\"children\":[{}]}";
        final var parent = objectMapper.readValue(json, Parent.class);

        assertThat(parent.children())
                .hasSize(1)
                .element(0)
                .extracting(Child::parent)
                .isNotNull();
    }

    record Parent(@JsonManagedReference List<Child> children) {}

    record Child(@JsonBackReference Parent parent) {}

}

Additional context

Is there a workaround whilst still being able to use records?

[cowtowncoder]

I doubt this is possible to support, unfortunately, due to immutable nature of records, and fundamental cyclic aspect of parent/child relationship.

Which means it'd probably be good to pro-actively fail on attempts to use these annotations with Records.

[JooHyukKim]

Proactively you mean during introspection, detect such usage, then throw error?

[cowtowncoder]

Yes

…

On Sun, Jun 15, 2025 at 9:01 AM Kim, Joo Hyuk ***@***.***> wrote: *JooHyukKim* left a comment (FasterXML/jackson-databind#5188) <#5188 (comment)> Proactively you mean during introspection, detect such usage, then throw error? — Reply to this email directly, view it on GitHub <#5188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANOGM2EZQQXHAFH63L6B33DWKGZAVCNFSM6AAAAAB7EYDIG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNZUGE2DMNJQG4> . You are receiving this because you commented.Message ID: ***@***.***>

[cowtowncoder]

Changed title to reflect actual work: since it is not possible to support combination of these references it is better to catch attempts to do so, instead of serialization "working" but then deserialization always failing.