Odd Boolean serialization when is-get and get method are both present

I have noticed that when trying to serialize a Boolean field, when both the is method and get method are present, Jackson will use the get method for serialization. Let’s take this example, and imagine to have an endpoint that returns the Person object by name:

public class Person {

    private String name; // Tatu

    private Boolean employed; // null

    public String getName() {
        return name;
    }

    // Jackson will use this method for serialization over isEmployed. The person endpoint for Tatu
    // will return
    //
    // {
    //    "name": "Tatu",
    //    "employed": null
    // }
    public Boolean getEmployed() {
        return employed;
    }

    // Jackson will use this method for serialization if getEmployed is commented and will return
    //
    // {
    //    "name": "Tatu",
    //    "employed": false
    // }
    public boolean isEmployed() {
        return Boolean.TRUE.equals(employed);
    }

}

When Jackson try to serialize the Person object it will use getEmployed() method to serialize the employed field. Of course if the getEmployed() method is removed, it will use the isEmployed(). I would be nice to have at least this behaviour documented.

I have a demo project, a trivial application using spring boot starter to simulate this behaviour at this link.

[cowtowncoder]

@SimoneGiusso right. It was good to verify this, given that I had forgotten what I had earlier implemented 😃

[cowtowncoder]

Ok, looked into this only briefly and realized that the precedence is defined as per a comment in POJOPRopertyBuilder method getGetter() when selecting amongst possibly multiple candidates:

            /* 30-May-2014, tatu: Three levels of precedence:
             * 
             * 1. Regular getters ("getX")
             * 2. Is-getters ("isX")
             * 3. Implicit, possible getters ("x")
             */

There is also a reference to issue #238 which defined the expected behavior (but one that I had already forgotten 😄 ). One problem with the implementation, however, is that it seems to hard code “get” and “is” prefixes even tho other parts of code allow custom prefixes.

But it looks like “regular” getters do have precedence over “is-getters” at this point (both of which have precedence over other prefixes that customized handlers might provide) and this is to be considered the expected behavior.