Introduction

For Java-style properties, the usual convention for a primitive boolean is isXxx() for the getter and setXxx(...) for the setter. The confusing part is that field names and wrapper types can shift what frameworks expect, so the cleanest choice is usually to name the field without an is prefix and expose isActive() and setActive(...).

The Standard JavaBeans Convention

For a primitive boolean property named active, the conventional accessors are:

1public class User {
2    private boolean active;
3
4    public boolean isActive() {
5        return active;
6    }
7
8    public void setActive(boolean active) {
9        this.active = active;
10    }
11}

This is the most widely recognized form by Java developers and by many tools that use JavaBeans-style introspection.

The getter uses is instead of get because the property type is boolean and the method reads naturally as a yes-or-no question.

Prefer Field Names Without The is Prefix

The most maintainable naming pattern is:

• field: active
• getter: isActive()
• setter: setActive(boolean active)

Why avoid private boolean isActive;? Because it often leads to awkward accessor naming questions:

• should the getter be isActive()?
• should the setter be setActive(...)?
• should frameworks treat the property as active or isActive?

You can make such names work, but they create unnecessary ambiguity.

Primitive boolean Versus Wrapper Boolean

For a primitive boolean, isActive() is the normal getter.

For a wrapper Boolean, many teams prefer getActive() instead:

1public class User {
2    private Boolean active;
3
4    public Boolean getActive() {
5        return active;
6    }
7
8    public void setActive(Boolean active) {
9        this.active = active;
10    }
11}

Why? Because Boolean can be null, so it behaves less like a simple yes-or-no primitive state.

Some frameworks still tolerate isActive() for Boolean, but getActive() is usually clearer when tri-state semantics are possible.

Frameworks And Tooling Care About This

Naming conventions are not only about readability. They also affect:

• serialization libraries
• ORM frameworks
• UI binding tools
• Lombok-generated accessors
• bean introspection in Spring and other Java frameworks

If your accessors are unusual, a framework may infer the property name differently than you intended.

That is why the simple active / isActive / setActive pattern remains the safest default.

A Few Examples

Good conventional example:

1private boolean enabled;
2
3public boolean isEnabled() {
4    return enabled;
5}
6
7public void setEnabled(boolean enabled) {
8    this.enabled = enabled;
9}

Less ideal but still seen in codebases:

1private boolean isEnabled;
2
3public boolean isEnabled() {
4    return isEnabled;
5}
6
7public void setEnabled(boolean enabled) {
8    isEnabled = enabled;
9}

This works, but the field name itself adds noise rather than clarity.

Interface And Record Considerations

In interfaces, the same getter naming rule usually applies:

public interface FeatureFlag {
    boolean isEnabled();
}

In records, you typically let the record component name define the accessor automatically, which changes the pattern because records do not generate JavaBeans-style isXxx() by default:

public record User(boolean active) {}

The accessor becomes active(), not isActive(). That is normal record behavior, but it is different from classic bean conventions.

Common Pitfalls

One common mistake is naming the field isActive and then generating accessors inconsistently across the project.

Another issue is using isXxx() for a nullable Boolean and forgetting that the value might be null, not just true or false.

A third problem is assuming frameworks will always interpret unusual boolean names the way humans do. Reflection-based tools are much happier with standard bean patterns.

Finally, developers sometimes treat record accessors and JavaBeans accessors as interchangeable, but they follow different conventions.

Summary

• For a primitive boolean property, the normal getter is isXxx() and the setter is setXxx(...).
• The cleanest field name is usually active, not isActive.
• For nullable Boolean, getXxx() is often clearer than isXxx().
• Standard naming matters because frameworks rely on accessor conventions.
• Records are a separate case and generate component-name accessors rather than bean-style boolean getters.