@JsonSetter affects serialization too

According to the docs, @JsonSetter is supposed to affect only deserialization and allow for “asymmetric naming”:

(…) this annotation was briefly deprecated for version 1.5; but has since been un-deprecated to both allow for asymmetric naming (possibly different name when reading and writing JSON) (…)

But it’s affecting serialization too. It’s behaving like @JsonProperty.

Jackson versions used:

+- com.fasterxml.jackson.core:jackson-core:jar:2.8.3:compile
+- com.fasterxml.jackson.core:jackson-databind:jar:2.8.3:compile
+- com.fasterxml.jackson.core:jackson-annotations:jar:2.8.3:compile
\- com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.8.3:compile
   +- com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.8.3:compile
   \- com.fasterxml.jackson.module:jackson-module-jaxb-annotations:jar:2.8.3:compile

Unit test:

import static org.junit.Assert.assertTrue;

import org.junit.Test;

import com.fasterxml.jackson.annotation.JsonSetter;
import com.fasterxml.jackson.databind.ObjectMapper;

class A {
    
    private Integer id;

    public A() {
    }

    public A(Integer id) {
        
        this.id = id;
    }

    public Integer getId() {
        return id;
    }

    @JsonSetter("number")
    public void setId(Integer id) {
        
        this.id = id;
    }
    
    /*
     * Workaround:
     * 
     * Change the name of the method above (setId) to something else and the bug goes away.
     * 
     */
}


public class JsonSetterTest {

    public <T> String toJSON(T to)
    {
        final ObjectMapper mapper = new ObjectMapper();

        try
        {
            return mapper.writeValueAsString(to);
        }
        catch (Exception e)
        {
            throw new RuntimeException(e);
        }
    }
    
    @Test 
    public void toJSON() { 
         
        A a = new A(1); 
         
        String json = toJSON(a);
        
        System.out.println(json);
        
        assertTrue(json.contains("id"));
    }
}

[tfga]

I don’t understand… Why would @JsonSetter have anything to do with serialization? And why would its behavior change depending on the name of the method it is attached to?

[cowtowncoder]

@tfga SInce you feel the need to ask such questions, you really, should to read how system works. Serialization and deserialization are closely tied, and naming is something that concerns both. And existing name of method is of crucial importance: this is the implicit name used to connect things. Without such linkage (between setX() and getX(), or plain T name()/name(T value)) more annotations would be used for renaming. While this is possible theoretically this is approach Jackson has taken. You are free to disagree with that approach, but you do not get define it.

It is true that there is redundancy currently in that @JsonSetter is not strictly necessary (any more, at least), but there is no meaningful way it could or should only affect deserialization, given that property discovery, including naming, is a shared concern between read and write sides.

And at this point this is as much time as I will spend on explaining the system.

As per my earlier note, yes, result is as expected. Implicit id property has been renamed as number, due to annotation. The way to prevent that is to use another annotation. Use case here is a minority use case compared to the case where renaming is expected to affect all accessors.