Choosing Between boolean and Boolean for POJO Fields: Naming, Default Values, and Serialization Implications

In everyday Java development we often need to expose a boolean flag in RPC interfaces to indicate whether a request succeeded. The article explores the pitfalls of defining such fields and provides guidance on choosing the proper type and naming style.

Four common declarations are shown:

boolean success
boolean isSuccess
Boolean success
Boolean isSuccess

The main difference is the use of the primitive boolean versus the wrapper Boolean . Primitive booleans default to false , while wrapper Booleans default to null , which can lead to NullPointerException if not handled carefully.

An example class demonstrates this behavior:

public class BooleanMainTest {
    public static void main(String[] args) {
        Model model1 = new Model();
        System.out.println("default model : " + model1);
    }
}

class Model {
    /** Define a Boolean type success member variable */
    private Boolean success;
    /** Define a boolean type failure member variable */
    private boolean failure;

    @Override
    public String toString() {
        return new StringJoiner(", ", Model.class.getSimpleName() + "[", "]")
                .add("success=" + success)
                .add("failure=" + failure)
                .toString();
    }
}

The output shows success=null and failure=false . The author recommends using the primitive boolean whenever possible to avoid null handling.

The article then discusses naming conventions. According to the Alibaba Java Development Manual, boolean fields should be named without the is prefix (e.g., success instead of isSuccess ) so that generated getter/setter methods follow the JavaBeans specification correctly.

Four POJO variants illustrate the effect of different field names and types on generated accessor methods:

class Model1 { private Boolean isSuccess; public void setSuccess(Boolean success) { isSuccess = success; } public Boolean getSuccess() { return isSuccess; } }

class Model2 { private Boolean success; public Boolean getSuccess() { return success; } public void setSuccess(Boolean success) { this.success = success; } }

class Model3 { private boolean isSuccess; public boolean isSuccess() { return isSuccess; } public void setSuccess(boolean success) { isSuccess = success; } }

class Model4 { private boolean success; public boolean isSuccess() { return success; } public void setSuccess(boolean success) { this.success = success; } }

When the field is named isSuccess , IDEs often generate an isSuccess() getter, which violates the JavaBeans rule that a boolean property isXxx should correspond to a field named xxx . This discrepancy causes problems during JSON serialization.

The article compares three popular JSON libraries (fastjson, Gson, Jackson) using the following serialization code:

Model3 model3 = new Model3();
model3.setSuccess(true);
System.out.println("fastjson:" + JSON.toJSONString(model3));
Gson gson = new Gson();
System.out.println("Gson:" + gson.toJson(model3));
ObjectMapper om = new ObjectMapper();
System.out.println("Jackson:" + om.writeValueAsString(model3));

fastjson and Jackson serialize the property as "success":true (derived from the isSuccess() getter), while Gson serializes it as "isSuccess":true (directly using the field name). Deserialization mismatches can therefore produce incorrect default values, leading to subtle bugs in production.

To avoid these issues, the author advises naming the field success and letting the getter be isSuccess() . This aligns with the JavaBeans spec and ensures consistent behavior across serialization frameworks.

Finally, a concise recommendation is given: define boolean response flags as boolean success in POJOs, especially for external APIs.