ParameterNamesModule sets attributes via reflection after calling constructor

[mabn]

I noticed that parameter names module behaves very weird when using custom naming strategy.
When using SNAKE_CASE naming strategy (probably others too):

• When constructor parameters are snake-case everything is fine
• When constructor parameters are camelCase I would expect naming strategy to kick-in and use the constructor in the same way. But the actual behaviour is:

  • constructor is properly called with all the correct attributes

  • but afterwards the attributes are set second time via reflection which effectively skips any code that could potentially alter their values in the constructor.

    The second set happens in PropertyBasedCreator.build because buffer.buffered() is not empty but I don't know jackson internals so I'm not sure if it's ok or not.

I've checked version 2.9.4.
Here's a test case reproducing the problem (and a runnable example with gradle):

import com.fasterxml.jackson.annotation.JsonCreator;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.PropertyNamingStrategy;
import com.fasterxml.jackson.module.paramnames.ParameterNamesModule;
import org.junit.Assert;
import org.junit.Test;

import java.io.IOException;

import static org.hamcrest.CoreMatchers.equalTo;

public class ParamNamesTest {
    private static final ObjectMapper mapper = new ObjectMapper()
            .registerModule(new ParameterNamesModule(JsonCreator.Mode.PROPERTIES))
            .setPropertyNamingStrategy(PropertyNamingStrategy.SNAKE_CASE);

    public static class Pojo {
        private final String firstAttribute;

        private final Long secondAttribute;

        public Pojo(String firstAttribute,
                    Long secondAttribute) {
            this.firstAttribute = "not-from-jackson";
            this.secondAttribute = secondAttribute;
        }

        public String getFirstAttribute() {
            return firstAttribute;
        }

        public Long getSecondAttribute() {
            return secondAttribute;
        }

        @Override
        public String toString() {
            return "Collaboration{" +
                    "firstAttribute='" + firstAttribute + '\'' +
                    ", secondAttribute=" + secondAttribute +
                    '}';
        }
    }

    @Test
    public void jacksonUsesConstructorOnly() throws IOException {
        String str = "{\"first_attribute\":\"alice\", \"second_attribute\":1267518}";
        Pojo pojo = mapper.readValue(str, Pojo.class);

        System.out.println(pojo);
        Assert.assertThat(pojo.getFirstAttribute(), equalTo("not-from-jackson"));
    }
}

[cowtowncoder]

First of all: thank you for reporting this, and especially including version affected.
I hope to verify this soon with 2.9.5, and assuming problem still remains (which seems likely), see what is going on. Usage looks fine. About the only thing you could try first is to add @JsonCreator to constructor, to ensure it is recognized (detection may fail for a few reasons, such as compiler not adding actual parameter name information in bytecode).

[mabn]

Thanks for looking at this.

Your intuition is correct, adding @JsonCreator helps and the test passes - so it's only a problem when the constructor is not annotated.

[cowtowncoder]

I think this is actually same as:

FasterXML/jackson-databind#806

and the unfortunate part is that it is rather difficult to fix, at least for 2.x.
So there is a chance that this might only get fixed for 3.0 where I hope to fully rewrite creator detection logic, basically so that property detection starts by considering Creators, which should allow keeping accessors (fields, getters, setters) and creator parameters in sync.

What happens here, essentially, is that implicit detection of constructors occurs too late for naming strategy to be applied, which leads to name discrepancy.

[cowtowncoder]

I don't think this is specific to parameter names module, and since there is matching issue for jackson-databind (see previous comment), closing this one as duplicate.