Skip to content

Jackson Release 2.8

Jump to bottom
Tatu Saloranta edited this page Apr 28, 2016 · 85 revisions

Version 2.8 development is planned to start in early 2016.

New Modules, status changes

Dataformat: Java Properties

First official version of https://github.com/FasterXML/jackson-dataformat-properties!

Possible maintenance changes

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

(note: a new owner was found for Scala module so it is not at risk)

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.

Planned features: Implemented

Following features from the initial planning list have been implemented (possibly partially):

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:

Chosen implementation mechanism is the new "type config overrides" mechanism, invoked as follows:

ObjectMapper mapper = ...;
mapper.configOverride(Wrapped.class).setIsIgnoredType(true);

which allows calling code to indicate that a given type is to be "ignored type".

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

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

Turns out the same mechanism - above-mentioned "type config overrides" -- may be used to also implement these two feature wishes. For example, to make all String arrays unwrap as a simple String on serialization, you could use:

mapper.configOverride(String[].class).setFormat(JsonFormat.Value.empty()
    .withFeature(JsonFormat.Feature.WRITE_SINGLE_ELEM_ARRAYS_UNWRAPPED));

This first version supports a subset of Class annotations, and does not yet have anything for per-property annotations. It should, however, be relatively straight-forward to extend similar approach to overrides of actual property.

Planned features: not-yet-implemented

Per-property "merge" option

Currently all property values are newly created "virgin" Objects. But sometimes it would be useful to see if property already had a default value (set by parent POJO in constructor, typically), and if so, modify that value.

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.

Change list

Changes, core

Annotations

  • #83: Add @JsonEnumDefaultValue for indicating default enum choice if no real match found

Streaming

  • #117: Add JsonParser.Feature.ALLOW_MISSING_VALUES to support for missing values
  • #253: Add JsonGenerator. writeEmbeddedObject() to allow writes of opaque native types
  • #254: Add JsonParser.finishToken() to force full, non-lazy reading of current token

Databind

  • #990: Allow failing on null values for creator (add DeserializationFeature.FAIL_ON_NULL_CREATOR_PROPERTIES)
  • #1084: Change TypeDeserializerBase to take JavaType for defaultImpl, not Class
  • #1126: Allow deserialization of unknown Enums using a predefined value (annotated with @JsonEnumDefaultValue)
  • #1136: Implement TokenBuffer.writeEmbeddedObject(Object)

Clone this wiki locally