Skip to content

Jackson Release 2.8

Jump to bottom
Tatu Saloranta edited this page Feb 12, 2016 · 85 revisions

Version 2.8 development is planned to start in early 2016.

New Modules, status changes

Possible changes:

  • Support: following modules may become "unsupported" if no maintainers are found:
    • Scala
    • Hibernate

Changes: compatibility

All language features of Java 7 will become available for components other than jackson-annotations and jackson-core (streaming).

Some of Java 2.8 features (most likely parameter names, and possibly Optional types) may be supported directly by jackson-databind instead of modules. Java 8 date/time types will almost certainly remain a plug-in option due to size.

Planned Features

Version 2.7 version had ambitious goals, but many of features originally planned had to be postponed to ensure that the main features started could be completed in time. Here's a list of features that are planned to be tackled for 2.8, in loose order of precedence.

Per-type defaults for Joda, Java Time (JSR-310) modules

With 2.6, date/time modules finally support @JsonFormat per-property overrides. There are also global defaults for some of the settings. But there is one more level of settings that make sense: per-type default settings, configured via module. For example, one may want to specify default format/pattern for, say, Joda DateTime, to be used globally unless overridden by @JsonFormat

2.7 did add better support for merging JsonFormat.Value instances, which should make it relatively straight-forward to support per-type defaults for various settings, including format.

Add per-property custom Serialization Inclusion mechanism

While it is possible to use @JsonInclude on properties, all choices use pre-defined rules; or, in case of NON_EMPTY (and by extension, NON_ABSENT) require matching JsonSerializer.isEmpty(...) to be implemented.

But it should be possible to have a simpler external exclusion handling. This could work by adding support for something like:

public class POJO {
  @JsonInclude(value=Include.MATCHING, matcher=MyMatcher.class)
  public Value value;

where an instance of MyMatcher will be created, and for each property value, MyMatchr.equals() is called to see if value matches: if it does (return true), value will be included; if not (false), it will be excluded.

Such an approach has the main benefit that since Object.equals() is defined for all types, no new types (interface, class) are needed. We can also easily use something like Void.class as the default value.

There are drawbacks as well:

  1. No context object can be passed so determination must be context-free (note: annotation types also can not refer to DatabindContext, so context, if any, would need to be untyped as well)
  2. Use of equals() is an abuse of semantics of the method.

Another approach would be to just create a new interface to fix the issues. Perhaps that makes more sense.

Allow pre-defining Object Ids; pluggable Object Id converters?

One of the things that has turned out problematic is resolution of Object References via Object Ids. There are a few improvements that could be considered:

  1. Allow pre-defining set of Object Id to instance mappings
  2. Allow custom resolution of Object Id references to instances

Fix Creator introspection

Although the hope was to add support for "annotation-less" constructors in 2.6, via implied naming, it turned out that there was one remaining big stumbling block: too-late discovery of "creator-capable" constructors.

Basically while it is possible to detect constructors that may act as Creators, due to all parameters having implicit names, this detection happens too late in processing: currently candidate properties (getters, setters, fields, constructor parameters) are collected first, and during this phase, only explicitly annotation constructors are considered. At a later point, all constructors are scanned again, and they are matched to properties that are backed by constructor. But "implied" creators found at this point can not be matched to properties, since they were not constructed during initial pass.

So discovery needs to be rewritten to either make implied-creator detection happen earlier altogether, or to speculative add properties from constructors first, and then decide which constructor, if any, is the primary; properties attached to other constructors will then be trimmed. Either way could potentially work; neither is trivially easy to implement.

Protobuf: Schema generation from POJO, building by hand

Protobuf support added in 2.6 was planned to allow 3 methods for defining protoc schema:

  1. Read from an external representation (File, String)
  2. Generate from POJO
  3. Create programmatically

but due to schedule, only (1) is supported. We should add missing modes.

Add more convenient alternatives to @JsonIgnoreType

Currently there are two ways to indicate an "ignorable type", one that as a property value type indicates that property should be ignored by default without further processing. This is typically needed to avoid serializing "hidden" properties that frameworks add. Methods that exist are:

  • Use @JsonIgnoreType on class itself (doable only if you can modify value classes)
  • Override method AnnotationIntrospector.isIgnorableType(...) to indicate ignorable status

There are a few issues filed for this from different modules:

Alternatives to Annotations (JsonFormat, JsonInclude first?) as config mechanism

One of longer term "Big Wishes" has been to be able to provide configuration overrides similar to use of Annotations and mix-in Annotations, but in a way that is not tied to annotations. This could be programmatic, or possibly external; the mechanism should be modular enough to allow variety of sources.

A natural extension point first seemed to be implementation of Annotation objects, but unfortunately JDK makes it next to impossible to actually implement Annotation types manually. As such, a variation is to start pairing Annotations with Value types constructed from Annotations: with 2.6, this is done for @JsonFormat and @JsonInclude, and more types could be supported as well. These value instances can be constructed from other sources as well.

The question of where alternate configuration could be injected is more interesting; as well as whether this could perhaps be implemented as general mechanism that works for all Annotations with matching Value type, without explicit code, or not. At this point it seems more likely that a small set of Annotations with Value types would be supported with explicit code.

As to extension point, it has been pointed out that AnnotationIntrospector is a somewhat reasonable extension point. This sounds like one possibility.

One practical limitation for the initial implementation is that the easiest thing to support are Class (type) annotations: supporting member/property annotations is much more difficult. But on the other hand, perhaps property overrides would not be as difficult, if they were inject after property introspection, as the last thing. If so, definition would NOT be tied to fields and methods, but to POJO type and property name. This could be relatively easy to support, powerful and simple. It might also avoid the question of precedence in type hierarchy; although might also introduce new issues (would base type overrides be used for subtypes? If so, would they still count as full overrides, or would expection be to somehow use them as "underrides"?)

Clone this wiki locally