Re: [jackson-dev] Java 8: Support for serializing and deserializing immutable objects without annotations.

[Christopher Currie]

Lovro, have we sent you a contributor agreement yet?

On Wed, Feb 19, 2014 at 3:33 PM, Tatu Saloranta <tsalo...@gmail.com> wrote:

On Wed, Feb 19, 2014 at 1:29 PM, Lovro Pandzic <lovro....@gmail.com> wrote:

I've added support for analyzing method parameter names and a few integration and one unit test for the ParameterNamesAnnotationIntrospector.

There are 2 issues left:

1. more javadoc

2. it seems that the ObjectMapper calls private constructor instead of static factory method annotated with @JsonCreator in the integration tests. Is it enough to annotate the method with @JsonCreator to designate it as the method for deserialization?

Yes, although there are additional signature requirements; main thing being that method has to be static for factory method, or constructor.

 

Are there any requirements before the integration of this fork?

Someone has to create the module skeleton, that's about only thing.

-+ Tatu +-

 

On Mon, Feb 17, 2014 at 9:36 PM, Tatu Saloranta <tsalo...@gmail.com> wrote:

On Mon, Feb 17, 2014 at 11:58 AM, Lovro Pandzic <lovro....@gmail.com> wrote:

Hello Christopher,

sorry for not responding sooner, it has been a busy week. Thanks for the tips.

I've managed to get the desired result - conversion of classes with no default constructor and without using annotations.

Current progress can be found on the forked repo page: https://github.com/lpandzic/jackson-datatype-jsr310/tree/jep-118.

Question related to testing: does ObjectMapper require of JSON object to have ordered name value pair?

No: ordering of properties is assumed to be undefined.

-+ Tatu +-

 

Regards,

Lovro Pandžić

On Sun, Feb 9, 2014 at 7:38 PM, Christopher Currie <chris...@currie.com> wrote:

What I would suggest you do is create a repository under your own account to do the initial development. We're happy to provide assistance and guidance as you go along. When it's ready, we can make a decision if it should be adopted as an official Jackson module.

To get you started, I'd look at the existing module for Java 8:

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

You can start by simply forking this module and adding the code and tests to this project; we can decide later if it should be separate from the 310 work.

Your key class is going to be NopAnnotationIntrospector; is has methods you can override for locating creators for a class. Then you'll register it using SimpleModule, to add it to the set of introspectors used by Jackson.

HTH,

Christopher

On Sun, Feb 9, 2014 at 2:29 AM, Lovro Pandzic <lovro....@gmail.com> wrote:

Hello all,

original issue with description can be found here: https://github.com/FasterXML/jackson-databind/issues/399.

I agree with Tatu's reply that jackson-module-jdk8 would be a natural place for introducing this feature.

About the '@JsonCreator' issue I'm a big fan of simplicity in the client code but I do agree that options should be present for clients that have high performance requirements.

I am willing to make a pull request to that repository once it's created. Currently I'm not familiar with the current codebase and I'd be thankful for tips.

Kind regards,
Lovro Pandžić

[Lovro Pandzic]

I've responded to the mailing list but not to the google group, is google group the preferred way of communication?

[Tatu Saloranta]

Yes; we are moving out of Codehaus, code to Github, mailing list to Google groups. Unfortunately I have not found a good way to indicate that Codehaus facilities (Jira, Confluence) are being deprecated, and this causes confusion.

-+ Tatu +-

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Tatu Saloranta]

I went ahead and created the JDK8 datatypes module:

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

which should be used for new datatypes introduced in JDK8.

There already existed one for JDK7:

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

and intent is to keep these non-overlapping.

-+ Tatu +-

[Lovro Pandzic]

Is this the right place to make a pull request for this task since it is not a datatype?

To repeat my question I've posted on the mail list but not here:

Can you please take a look at ParameterNamesResolverDeserializationTest tests that are deserializing ImmutableBeanWithStaticFactory. It seems private constructor gets called directly instead of the public static factory method annotated with @JsonCreator.

Regarding the contributor agreement: no, I haven't received it.

[Tatu Saloranta]

Good question. I think this is appropriate module, regardless; we can think about whether naming should be changed (it's easy enough to change before we cut releases). I chose name since I was guessing most things would be datatype additions.

So let's start by assuming this is the project.

As to CLA, you can document under this project:

https://github.com/FasterXML/jackson

and artifact is:

https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf

once filled (usual way is to print it, sign, scan, email) it should be sent to "info" at fasterxml dot com; only one CLA is needed per contributor, for all Jackson projects.

-+ Tatu +-

--
You received this message because you are subscribed to the Google Groups "jackson-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Lovro Pandzic]

I have opened a new issue about documenting this new feature in the README.md. Is there any more work to be done before this module can be released?

[Tatu Saloranta]

I haven't had time to go over this in detail, but I think that if you would find it useful for your own code, I have no problems releasing it. If it works with 2.3.2 core components, I could release 2.3.2 version, whether it would be called experimental or not.

-+ Tatu +-

[Lovro Pandzic]

I think the issue related to the static factory method usage should be addressed first.

When you get the time please take a look at ParameterNamesResolverDeserializationTest class and the tests related to the ImmutableBeanWithStaticFactory.

If you modify the ImmutableBeanWithStaticFactory constructor:

private ImmutableBeanWithStaticFactory(String name, Integer value, Object notNull) {

    Objects.requireNonNull(notNull);

    this.name = name;
    this.value = value;
}

and the static factory:

@JsonCreator
public static ImmutableBeanWithStaticFactory of(String name, Integer value) {

    return new ImmutableBeanWithStaticFactory(name, value, new Object());
}

The problem becomes evident from failing tests.

Lovro

[Tatu Saloranta]

Is there a bug filed for the issue (for jackson-databind)?

-+ Tatu +-

[Lovro Pandzic]

No, currently there isn't but I can make it. Support for static factory methods currently isn't documented in javadoc (nor mentioned) but I think it should be. I don't have a better idea to isolate this issue with a test other than the one before mentioned. Other part of the problem is I didn't have the time to identify why isn't the static factory method getting called.

Lovro

[Tatu Saloranta]

Hmmh? Do you mean not supported by this new module? Core jackson-databind does support use of static factory methods as creators.

If so, yes, it would be good to support this. And if so, adding issue for the new module would make sense so that all contributors are aware of missing functionality; it may be simple enough to add support.

-+ Tatu +-

[Lovro Pandzic]

New module does support identifying the parameter name on methods. The problem is that the core chooses to call private constructor over the public static factory method annotated with @JsonCreator. Signature of constructor is longer (3 parameters vs 2) and before the core makes it's choice it queries the introspector both about the parameter names of static factory and constructor.

Lovro

[Tatu Saloranta]

Ah. That sounds sub-optimal: explicit annotation should have precedence.

A bug report for jackson-databind would be warranted for this.

-+ Tatu +-

[Lovro Pandzic]

I wrote a test to help resolving the issue: https://github.com/lpandzic/jackson-databind, branch json-creator-priority-test and the test class is TestJsonCreatorPriority.
It boils down to this: if the annotation introspector is able to resolve parameter names for both constructor and static factory method, the core doesn't take into account the JsonCreator annotation while deciding which one to use for deserialization.

Lovro

[Tatu Saloranta]

Could you file a bug against jackson-databind, if you have not done so already? And link the test from there -- that is a very helpful thing to have, thank you for reproducing the problem.
It does sound like a flaw in processing indeed.

-+ Tatu +-

For more options, visit https://groups.google.com/d/optout.

[Lovro Pandzic]

I've just created the issue for this problem - https://github.com/FasterXML/jackson-databind/issues/421.

Lovro