Opt a hierarchy in with a Jackson mix-in

[pjfanning]

An alternative to #1 for the same problem — a sealed hierarchy whose source cannot be changed to extend SealedPolymorphismSupport. Instead of registering the type with the module, register a mix-in that extends the marker with the mapper. Branched off main, so the two can be compared independently.

Follows jackson-module-scala's ea02e0f.

// yours, in your own package
public interface AnimalMixIn extends SealedPolymorphismSupport {}

ObjectMapper mapper = JsonMapper.builder()
        .addModule(new SealedPolymorphismModule())
        .addMixIn(Animal.class, AnimalMixIn.class)
        .build();

The mix-in carries the marker and nothing else, and lives in its own package as a third party's would. It does not extend the hierarchy it is mixed into, and could not: a sealed type's permits clause names its subtypes, and someone who cannot change those classes cannot add themselves to it. Jackson never requires a mix-in to be a subtype of what it is mixed into.

What this costs

A mix-in does not change the type on the JVM, so unlike the marker it is not inherited by the implementations — only the root is opted in, and the module has to read that from the mapper's configuration. Three consequences:

• The opt-in check and root resolution take the MapperConfig (as a MixInResolver).
• The walk up from a type can no longer stop at a supertype that has not opted in, since a mixed-in root may sit above several plain classes.
• The deserializers take the resolved hierarchy rather than looking it up, since only their construction sites have the config.

Which root a type belongs to can now differ between mappers, so that is no longer cached by class. A root's name table is derived from the class files alone and is identical however that root opted in, so that half stays cached.

There is no new public API at all — addMixIn is Jackson's, and the marker interface already exists.

A mix-in can also opt out

Mix-in	Result
does not extend SealedPolymorphismSupport	opts nothing in — the hierarchy stays untouched
carries @JsonTypeInfo as well as the marker	the module stands down, as it does for the annotation on the class

Held to the same rules

A mixed-in hierarchy must still be sealed, a non-sealed member is still reported, and enums are still left to Jackson. Mixing into a type part way down a hierarchy makes that type the root.

Comparison with #1

	#1 registerSealedInterfaceOrClass	this PR, mix-in
Opt-in lives on	the module	the mapper
New public API	one method	none
Bad input reported	at the register call	when Jackson first meets the type
Per-mapper	only if modules are not shared	inherently
User writes	nothing extra	a one-line marker interface per hierarchy

Tests

14 in MixInTest, against a new MixInFixtures of ordinary sealed hierarchies that do not reference this module at all, plus mix-ins in a separate poly.mixin package. Everything a mixed-in hierarchy is held to is asserted against the same shapes as the marked ones: naming, concrete roots, mid-hierarchy roots, enums, not sealed, reopened below the root, and coexisting with a marked hierarchy in one mapper.

90 tests total.

🤖 Generated with Claude Code

https://claude.ai/code/session_012hxYY9KPDAMXADWzjBHNV4