Support for sealed classes in Java

[nlisker]

Sealed classes are coming to Java soon. Jackson can use them to remove the need to specify @JsonSubTypes because they are known from the sealing class:

@JsonSubTypes({
	@JsonSubTypes.Type(value = A.class),
	@JsonSubTypes.Type(value = B.class)
})
public interface L {

	record A(int a) implements L {}

	record B(int b) implements L {}
}

can be

public sealed interface L {

	record A(int a) implements L {}

	record B(int b) implements L {}
}

[cowtowncoder]

This sounds similar to what Kotlin does; would make sense I think.

One possible concern is that of whether users sometimes might not want to automatically enable polymorphic handling... and come to think of that, it is not clear which inclusion mechanism should be used.
So I suppose in above examples one should still use @JsonTypeInfo to opt-in and specify mechanism (type id to use (Class name vs Type name); inclusion mechanism (property, as-wrapper-array, as-wrapper-object)).
But it is true that all subtypes would be easily discoverable without explicit @JsonSubTypes annotation.

[nlisker]

So I suppose in above examples one should still use @JsonTypeInfo

Correct.

Sealed classes are in preview right now, but soon will be released as a core feature. I suggest looking into this in preparation for their release.

[slutmaker]

@cowtowncoder any updates on this?

[cowtowncoder]

@AbstractCoderX no

[almson]

I don't think it would be a backwards-incompatible change to have @JsonSubTypes take priority, but for sealed classes that have @JsonTypeInfo but not @JsonSubTypes for the sub types to be inferred.

[sigpwned]

I'm considering taking a stab at this.

@cowtowncoder, is there any place in particular you'd like to see in a PR?

On face, this feels like a FasterXML/jackson-databind concern, but obviously records aren't available until Java 15 (at the earliest), so that probably isn't feasible.

I see a project FasterXML/jackson-modules-java8. Would it make sense to create an implementation in a new public repository (of my own) titled "jackson-modules-java17" (that targets Java 17) modeled after jackson-modules-8, and share it here? And then if it passes muster, you could fork it/create a new repo and I would PR into it/whatever? Or is that a bad approach?

Happy to tackle this in whatever way you think is best!

[pjfanning]

My 2 cents would be to try your own standalone module and Jackson can possibly take over the module later.

[sigpwned]

Good suggestion, @pjfanning. I think that's a much more sane approach. I'll report any progress back here.

[sigpwned]

OK, I've got a module for simplified serialization of Java 17 sealed classes that seems to work pretty well up at sigpwned/jackson-modules-java-17-sealed-classes. (Thanks again, @pjfanning, this was definitely the right approach to take.)

The module is based on some reading from this issue in the Kotlin module.

The build includes a (reasonably) good battery of serialization and deserialization tests that ensure the new feature works and the existing functionality hasn't changed.

New Features

This module allows the following (simpler) code to work for serializing sealed classes:

@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "type")
public sealed class SealedExample permits AlphaSealedExample, BravoSealedExample {
}

@JsonTypeName("alpha")
public final class AlphaSealedExample extends SealedExample {
}

@JsonTypeName("bravo")
public final class BravoSealedExample extends SealedExample {
}

In particular, I'm pleased that there is no repetition of type names or any such thing. The implementation works without the @JsonTypeName annotations, too, but falls back on (potentially awkward) default names.

Implementation

For convenience, the (abridged, for clarity) crux of the implementation is here:

public class Jdk17SealedClassesAnnotationIntrospector extends JacksonAnnotationIntrospector {
  @Override
  public List<NamedType> findSubtypes(Annotated a) {
    if (a.getAnnotated() instanceof Class<?> klass && klass.isSealed()) {
      Class<?>[] permittedSubclasses = klass.getPermittedSubclasses();
      if (permittedSubclasses.length > 0) {
        return Arrays.stream(permittedSubclasses).map(NamedType::new).toList();
      }
    }
    return null;
  }
}

This implements a new AnnotationInspector for discovering subtypes that is appended as a new "last resort" option by the module. If I were trying to integrate the new code into JacksonAnnotationIntrospector, though, it would probably look like this earlier draft:

public class Jdk17AnnotationIntrospector extends JacksonAnnotationIntrospector {
  @Override
  public List<NamedType> findSubtypes(Annotated a) {
    // This is the "existing" subtype implementation, which uses the @JsonSubTypes annotation to
    // allow for polymorphic de/serialization. We
    List<NamedType> result = findSubtypesByAnnotation(a);
    if (result == null)
      result = findSubtypesByPermittedSubtypes(a);
    return result;
  }

  protected List<NamedType> findSubtypesByAnnotation(Annotated a) {
    return super.findSubtypes(a);
  }

  protected List<NamedType> findSubtypesByPermittedSubtypes(Annotated a) {
    if (a.getAnnotated() instanceof Class<?> klass && klass.isSealed()) {
      Class<?>[] permittedSubclasses = klass.getPermittedSubclasses();
      if (permittedSubclasses.length > 0) {
        return Arrays.stream(permittedSubclasses).map(NamedType::new).toList();
      }
    }
    return null;
  }
}

Possible Next Steps

All feedback welcome. If this seems like a worthy addition to the library proper, then I'd be happy to submit a PR, preferably with a little guidance on how best to package it.

Thanks again all for the help!

[cowtowncoder]

Very cool.

I think this could potentially even be included in core databind, but that would require doing something similar to detection of record types: use basic reflection to find methods dynamically so that things still work on JDK 8 (but obviously sealed classes wont' be there).

Aside from this, one thing that we would need would be one more MapperFeature to allow disabling functionality -- just in case someone somewhere did not want this auto-detection.

I would be happy to help get things merged if you @sigpwned wanted to work on something like this.

Alternatively there might be a way to add a new JDK 17 module somehow. I guess we'd want new "jackson-modules-java17" or something; perhaps there might be other JDK 17 functionality to support (I am not fully up to what all is included, aside from it being first LTS with records).

[sigpwned]

@cowtowncoder awesome!

If I'm tracking, then the record support in core databind is in JDK14Util. I grok that code, and I can absolutely take a swing at implementing it for the sealed classes feature. I'll update with progress here.

[pjfanning]

I don't want to nix any dev work here but with recent JDKs, reflection is frowned on. I would have preference for a separate module that does not use reflection - leaving jackson-databind as is. But I'll accept the consensus on this.

[cowtowncoder]

Good point @pjfanning. I am bit torn here: you are right, reflection is kind of frowned upon.
Then again we already do use it for Records so in a way damage is done, and I don't see 2.x moving to Java 17 baseline any time soon. So functionality needs to be maintained for quite a while.

Now... one other thing to consider: I haven't yet brought this up on mailing lists, but I am thinking that maybe Jackson 3.x (master branch) should require JDK 17 as the baseline. Initially this was to get Record types in cleanly.
If this was done we could then support this aspect natively in 3.x and via Reflection in 2.x.

[sigpwned]

For my part, I'm happy to tackle it any which way you guys decide!