Code Review · Java · Correctness

Java Code Review: == vs equals()

Review Java code that compares strings or objects using == instead of equals().

Code ReviewJavaStringsEquality

Code Review Exercise

Imagine an interviewer shows you this code and asks: what issues do you see?

java

public class UserService {
    public boolean isAdmin(User user) {
        return user.getRole() == "ADMIN";
    }
}

Before jumping to the fix, review it like a real code review: correctness, edge cases, readability, maintainability, and design.

What You Should Catch First

The biggest correctness issue is this line:

java

return user.getRole() == "ADMIN";

In Java, == checks whether two references point to the same object. It does not reliably check whether two strings have the same characters.

For logical string comparison, use equals().

Review Findings

Issue #1: == compares references

The code may pass in some cases because of Java string interning, but it is not reliable. If the role string comes from a database, API, request body, or constructed value, == may return false even when the text is ADMIN.

Issue #2: Possible NullPointerException

Changing the code to user.getRole().equals("ADMIN") is better for equality, but it can throw NullPointerException if getRole() returns null.

Issue #3: Magic string

The role ADMIN is hard-coded as a string. In a larger application, an enum or constant is usually safer and easier to maintain.

Issue #4: Missing null handling for user

If user itself can be null, this method can still throw NullPointerException. Whether to handle that depends on the contract of the method.

Better Version

A safer string-based version puts the constant first:

java

public class UserService {
    public boolean isAdmin(User user) {
        if (user == null) return false;

        return "ADMIN".equals(user.getRole());
    }
}

This avoids the string comparison bug and avoids a null pointer if getRole() returns null.

Even Better Version With an Enum

If roles are known values, an enum is usually cleaner than passing strings around.

java

enum Role {
    ADMIN,
    USER,
    SUPPORT
}

public class User {
    private Role role;

    public Role getRole() {
        return role;
    }
}

public class UserService {
    public boolean isAdmin(User user) {
        return user != null && user.getRole() == Role.ADMIN;
    }
}

Using == with enums is fine. Enum values are singletons, so reference comparison is the normal Java style for enums.

How To Explain This In an Interview

A strong review answer could sound like this:

The first issue I see is that this code uses == to compare a String. In Java, that compares object references, not logical equality. It may appear to work for string literals because of interning, but it can fail when the value comes from outside the code. I would use "ADMIN".equals(user.getRole()) to avoid both the equality bug and a possible null pointer. If roles are fixed values, I would prefer an enum instead of a raw string.

Common Interview Follow-Ups

Does == ever work for Strings?

It can appear to work when both strings refer to the same interned literal, but you should not rely on that for logical string comparison. Use equals().

Why write "ADMIN".equals(user.getRole()) instead of user.getRole().equals("ADMIN")?

The constant-first version is null-safe. If getRole() returns null, the expression simply returns false instead of throwing NullPointerException.

Can you use == with enums?

Yes. In Java, enum values are singletons, so comparing enum values with == is normal and preferred.

What if user should never be null?

Then the method contract should make that clear. You might still validate earlier, use Objects.requireNonNull(user), or leave the null check out if the codebase consistently treats null as a programming error.

Final Takeaway

In Java code review, == vs equals() is a correctness issue. Use equals()for logical object equality, use constant-first string comparison when null is possible, and prefer enums when the value is one of a fixed set of choices.