Java 8: Support for serializing and deserializing immutable objects without annotations.

[lpandzic]

To serialize/deserialize immutable objects currently you have to add annotations like this:

public final class Point {

    private final int x;
    private final int y;

    @JsonCreator
    public Point(@JsonProperty("x") int x, @JsonProperty("y") int y) {

        this.x = x;
        this.y = y;
    }
}

One obvious downside to this appcorach is that it adds complexity and pollutes the source code.

This can be solved by using the new API for formal parameters names retrieval in Java 8.
To pick the constructor following strategies could be used:

• @JsonCreator for explicit declaration
• implicitly reasonable default should be used such as constructor with longest parameter list.

[cowtowncoder]

Jackson has JDK6 as the baseline, and it won't be possible use any JDK8 for quite a while.

But there has been talk about creating jackson-module-jdk8 (or -java8) which would be natural place for such improvement. I think that would be a good idea, perhaps also worth discussing (again) on jackson-dev mailing list.

I think this could omit need for @JsonProperty. Question of @JsonCreator is bit trickier; could perhaps have a feature to enable auto-detection; I am bit wary of advanced heuristics between default (no-args) constructor and one or more alternatives. Although existence of a single public multi-arg constructor might be good enough hint.

[cowtowncoder]

I created:

https://github.com/FasterXML/jackson-datatype-jdk8

so this will move to that module.

[mmc41]

Brilliant with the Java 8 support retrieving parameter names in CTRs for immutable objects. I am strongly considering using Jackson instead og JAXB just because of the new jackson-datatype-jdk8 module.

[lpandzic]

I'm sorry to inform you that the module supposed to add this feature to jackson called jackson-module-parameter-names is not fully functional yet and my work on it has been halted due to my other project. It still requires the use of @JsonCreator thus limiting it's usability.

If you are interested please respond to the topic regarding this module on jackson-dev mailing list.
I'd gladly continue my work if we could reach a consensus about the module.

[mmc41]

That is unfortunate since this new feature (arguably best if not requiring @JsonCreator) is revolutionary and would make Jackson a clear winner.

[cowtowncoder]

I don't see any blockers for work on java8 Jackson module. As per above, jackson-databind itself can not use Java8 features, but java8 module can. Requirement to use @JsonCreator is there, sure, but I can't see that as a blocker for initial support; and even then it is possible to improve that aspect incrementally.

[lpandzic]

That is unfortunate since this new feature (arguably best if not requiring @JsonCreator) is revolutionary and would make Jackson a clear winner.

After some testing my previous statement doesn't seem to be true and the README.md is wrong. Current implementation of the module doesn't check anything about the @JsonCreator (just take a quick glance at the implementation) so it can work without @JsonCreator.

The real problem is the situation in which you use @JsonCreator. For example, lets say a class has identical constructor and static factory method (identical in term of parameter names and types) and the static factory method is annotated with @JsonCreator. Since the module ignores the @JsonCreator and jackson-databind inherently prefers use of constructors, deserialization of this class will result in the constructor being called instead of the static factory method. This presents a violation of the @JsonCreator contract.

The source of this problem is the fact that jackson-databind is "coupled" to the current shortcoming of the JacksonAnnotationIntrospector. JacksonAnnotationIntrospector cannot resolve the parameter names without @JsonProperty and it doesn't make any sense from the client side to write @JsonProperty without using @JsonCreator. This coupling is documented in this issue.

This problem can not be simply solved in the module alone because of the way the current API available to the module for resolving parameter names works. The API, which mainly consists of the method PropertyName findNameForDeserialization(Annotated annotated), is called on the module multiple times for each parameter available but in no predefined order which makes it impossible to detect when the module should not return the parameter name (in case a class does have a @JsonCreator).

Now in order for the module to abide by the contract of @JsonCreator it should mimic JacksonAnnotationIntrospector and not return parameter names in cases where a @JsonCreator is present and the currently inspected parameter is not it's member.

Yesterday I've been playing around with a possible, although hackish, solution.
The basic idea goes like this - for every new class that is presented to the module it scans the whole class for @JsonCreator. In case where no @JsonCreator is present the module can work as normal.
In case a @JsonCreator is present we need to store that information and not resolve parameter names for constructors/methods which are not annotated with @JsonCreator. This solution does abide by the contract but has cons of it own:

• it doesn't feel right scanning the class for @JsonCreator, the jackson-databind should do it before calling the module
• the information whether the scanned class has @JsonCreator should be cached since I doubt it's cheap to scan it for every findNameForDeserialization call
• the cache (map) implementation choice is deferred to the client since there is no real implementation of a cache map available in the JDK

I don't see any blockers for work on java8 Jackson module. As per above, jackson-databind itself can not use Java8 features, but java8 module can. Requirement to use @JsonCreator is there, sure, but I can't see that as a blocker for initial support; and even then it is possible to improve that aspect incrementally.

I think he's trying to say what I've been saying for some time - gain of this module is greatly diminished if you still must use @JsonCreator for all immutable classes. I'm not saying that we should ignore @JsonCreator but I'm saying that we need to resolve this issue for parameter names module to be useful/successful.

[mmc41]

How would scanning work? You would need some way to limit which classes are scanned otherwise it could SLOW startup of an application up like I have observed with other tools. Also, there is the principle of least surprise. One should not be surprised that a immutable class is instantiated by jackson. Maybe an annotation (and maybe a new one) on package or class level would be ok (but not all constructors which too intrusive and to much I think).

[lpandzic]

Scanning is done only on the classes that are to be serialized/deserialized and only when first asked by jackon-databind (with the method I mentioned in my previous reply). The AnnotatedParameter that is passed to the module contains the information about the constructor/method to which the parameter belongs and also the class. The scanning is done on that class and the scanning is only looking for @JsonCreator on methods/constructors.

@cowtowncoder I haven't found any documentation about whether one or more @JsonCreator are possible per class? I'm assuming that only one is allowed.

[cowtowncoder]

@lpandzic Only one is currently allowed for constructor, and one for factory method.

[cowtowncoder]

Ok one other relevant thing wrt AnnotationIntrospector: as of 2.4, there is one new method, findImplicitPropertyName(), which differs from findNameForSerialization/findNameForDeserialization in that result does not indicate that parameter name is not explicitly annotated by developer. Distinction mostly matters to property renaming (implicit names are overridden by explicit names), but matters here as well -- databind is able to tell difference between something marked with @JsonProperty, and something that isn't.

But there is still the problem that distinction between two types of creators:

1. "Delegating" creator: one argument without explicit name, and
2. "Property-based" creator: one or more arguments, all with explicit name (or marked as injectable)

where expectation of explicit names is problematic at first; but if relaxed (to allow implicit names), case between 1 and 2 becomes problematic; basically it is not possible to distinguish which one is meant for creator with one argument.

For this, one possibility would be to add a new property for @JsonCreator, which would explicitly indicate type of creator using enumeration (delegating, property-based... and perhaps "auto" as default?). This would resolve possible ambiguity.

This would only help in this particular problem, and not remove the need to use @JsonCreator, or allow use of multiple creators (of which most optimal is chosen).
But it could be a start, and would be easy to add for 2.5.

[lpandzic]

Only one is currently allowed for constructor, and one for factory method.

It is possible to have 2 JsonCreators on one class?

About the issue I mentioned in my previous, longer post, please take a look at this gist. If ran against jackson-module-parameter-names 2.4.1 it will fail which demonstrates the issue with implicit constructor preference.

About the problem with distinction between two types of creators, can you make a test (gist) to demonstrate it?
I'll try to finish the prototype I mentioned before which doesn't force use of @JsonCreator and still passes the before mentioned test.

[cowtowncoder]

What I meant by "one for constructor, one for factory" method is that it is possible to technically have two instances of @JsonCreator annotation; but even then, it resolves into exactly one creator method.
There is no support for dynamically choosing from set of more than one creators.

As to difference, I think the only case is simple one-argument case like:

public class X {
   public X(String value) {
       ...
   }

where question is whether this should be mapped from JSON String (delegating creator), or from JSON Object like { "value" : "something" }. With current rules it would be deemed delegating creator (i.e. require JSON String to match), but if explicit name was specified (with @JsonProperty), it would be seen as property-based creator. This is not problematic before implicit names since explicit names are needed anyway.

But maybe this is more a documentation issue: in case of single-argument creator, explicit name must be added, to avoid use as delegating creator. Or, alternatively, by introducing 'type' for @JsonCreator.
Or... If deserialization process was extended to allow multiple creators, one could perhaps allow both, depending on type of incoming Object.

A prototype would be good.