Logical Operators in Java: Combining Conditions With &&, ||, and !

Java's logical operators take boolean operands and produce a boolean. There are exactly three, and unlike the bitwise operators from the previous topic, none of them accept numbers.

boolean a = true;
boolean b = false;
System.out.println(a && b);
// false
System.out.println(a || b);
// true
System.out.println(!a);
// false

Two compile errors are worth internalising, because they are the clearest way to see the difference from the bitwise family.

boolean p = true;
boolean q = true;
System.out.println(p ^ q);
// false, legal, this is the bitwise XOR on booleans
System.out.println(p & q);
// true,  legal, the bitwise AND on booleans
System.out.println(!5);
// error: bad operand type int for unary operator '!'
System.out.println(~5);
// -6,  legal, this is bitwise complement instead
System.out.println(p && 5);
// error: bad operand types for binary operator '&&'

! negates truth, not bits. To flip the bits of a number you want ~, which is the subject of the unary operators topic.

The truth tables are identical to the bitwise operators, which is not a coincidence since & and && agree on booleans. What differs is whether the second operand is evaluated at all.

The useful way to read the tables is as an early exit. For &&, a false left operand settles the answer, and for ||, a true left operand settles it. One row in each table is the interesting one, and those two rows are exactly where the right-hand side gets skipped.

a b | a && b reads as | a || b reads as ---- ---- + ---------- ---------------- + ---------- ---------------- F F | false b not needed | false both needed F T | false b SKIPPED | true b not needed T F | false both needed | true b SKIPPED T T | true both needed | true b not needed

Short-circuiting means the right-hand operand is evaluated only when the left one has not already determined the answer. It is not an optimisation bolted on afterwards; it is the defined behaviour of the operator.

To see it, give each operand a visible side effect.

static boolean t(String name) {
    System.out.println("  evaluated " + name);
    return true;
}static boolean f(String name) {
    System.out.println("  evaluated " + name);
    return false;
}if (t("a") || t("b") || t("c")) {
    // only "a" is ever printed
}if (f("a") && f("b") && f("c")) {
    // only "a" is ever printed
}

t("a") || t("b") || t("c") "a" is true, so the whole expression is already true and b and c are never called evaluated a f("a") && f("b") && f("c") "a" is false, so the whole expression is already false and b and c are never called evaluated a

A counter makes it unambiguous.

int[] calls = {
    0
};
boolean r1 = false && bump(calls);
// false
boolean r2 = true || bump(calls);
// true
System.out.println(calls[0]);
// 0, bump never ran at all

Note that both chains stop after the first operand. && and || are short-circuiting all the way down, so in a longer chain like a || b || c you may evaluate only one or two of the three.

The reason short-circuiting matters far beyond performance is that it turns a sequence of conditions into a safety mechanism. The right-hand side only runs when it is safe to run.

String text = null;
if (text != null && text.length() > 0) {
    System.out.println("Text is valid");
} else {
    System.out.println("Text is null or empty, and no exception was thrown");
}

The output is the else branch, and nothing blows up. Swap && for the non-short-circuiting & and the same code throws.

text != null && text.length() > 0 text != null is false -> answer is already false text.length() is never called, so no NullPointerException text != null & text.length() > 0 text != null is false, but & evaluates BOTH sides regardless text.length() is called on null -> NullPointerException

try {
    if (text != null & text.length() > 0) {
        // never reached
    }
} catch (NullPointerException e) {
    System.out.println(e.getMessage());
}

The message is Cannot invoke "String.length()" because "" is null. That single difference between & and && is the whole reason the guard idiom exists.

The same pattern works with ||, where the guard simply inverts.

if (text == null || text.isEmpty()) {
    System.out.println("The || form caught it, and isEmpty() was never called");
}

Both forms work. The && version says proceed only if valid, while the || version says bail out if invalid. Pick whichever reads better, and put the risky condition on the right.

Because evaluation stops early, the order of the conditions inside a single chain is not cosmetic. Put the cheap and safest test first, since a wrong order either throws or does work you did not need.

// cheap first: the array length is a field read
if (items.length > 0 && items[0].getName().isEmpty()) {
    ...
}// risky first: dereferences items[0] before checking there is anything at index 0
if (items[0].getName().isEmpty() && items.length > 0) {
    ...
}

The second version throws ArrayIndexOutOfBoundsException on an empty array, because the left operand is evaluated before the length is ever consulted. The same applies to method calls: put the cheap boolean field before the expensive database call.

guard clause ordering always put the cheap, side effect free test first always put the dereference, the network call or the allocation second cost of a wrong order is not just performance, it is a crash

The three operators have a fixed binding order, strongest first: ! binds tighter than &&, which binds tighter than ||. This is the single most common source of a condition that does not do what it looks like.

System.out.println(true || false && false);
// true
System.out.println((true || false) && false);
// false

The first line is true because && is evaluated first, giving true || (false && false), which is true. Written the other way round it is false. They look similar and mean opposite things, which is exactly the trap.

! binding tighter than && is the second half of the same trap.

System.out.println(!false && true);
// true,  parsed as (!false) && true
System.out.println(!(false && true));
// true,  same answer by coincidence

Whenever the grouping is not obvious, write the parentheses. The compiler does not warn you, and neither does the reader.

De Morgan's laws let you push a negation down through a compound condition. There are two, and both hold in Java.

boolean a = true;
boolean b = false;
System.out.println(!(a && b));
// true
System.out.println(!a || !b);
// true
System.out.println(!(a || b));
// false
System.out.println(!a && !b);
// false

Verified across all four input combinations, both forms give the same answer every time.

for (boolean p : new boolean[] {
    false, true
}) {
    for (boolean q : new boolean[] {
        false, true
    }) {
        System.out.println(p + " " + q + " -> " +(!(p && q)) + " and " +(!p || !q));
    }
}

The reason to care is readability. A negated compound condition is hard to follow, and the usual fix in Java is to pull the negation inward until each test is a plain positive check.

// harder to read
if (!(user != null && user.isActive())) {
    return;
}// easier, and De Morgan has been applied for you
if (user == null || !user.isActive()) {
    return;
}

The same rewrite is what makes it safe to move the null test into the negation, since !(a && b) becomes !a || !b and only then is it obvious that b is guarded by a.

Java reuses the bitwise operators on booleans, and on booleans they produce the same truth value. The single difference is that & and | always evaluate both operands, which Topic 26 covered from the bitwise side.

There are two situations where the non-short-circuiting form is genuinely the right choice, and they are both about evaluating both sides for effect rather than for value.

boolean a = f();
// f prints as it runs
boolean b = f();
boolean r1 = a && b;
// if a is false, b still runs here, because f() already assigned it
boolean r2 = a & b;
// both are forced into an expression, so the intent is explicit

The second is a readability choice when you want to signal that evaluation order does not matter, which is uncommon. Outside of that, use && and || for every ordinary condition.

The most valuable use of the short-circuit behaviour is the guard clause, which inverts a nested if into a flat test at the top of the method. Deeply nested conditions are where logic bugs hide, and the guard form removes a whole indentation level plus one branch.

// nested, and every extra level is a chance to get the logic wrong
if (user != null) {
    if (user.isActive()) {
        if (user.hasPermission("edit")) {
            doEdit();
        }
    }
}// flat, and the same three conditions
if (user == null) return;
if (!user.isActive()) return;
if (!user.hasPermission("edit")) return;
doEdit();

The flattened version also removes the "arrow anti-pattern", where a long line of repeated returns walks off the right edge of the screen. And because each guard can use &&, the checks can be combined when it improves readability.

if (user == null || !user.isActive() || !user.hasPermission("edit")) {
    return;
}doEdit();

Both forms are correct. Combine them when the tests are related and short-circuiting makes the combination safe, and split them onto separate lines when each one deserves its own comment or its own error message.

The ternary operator ?: has the lowest precedence of the three logical operators, so a logical expression as its condition needs no parentheses. That is worth confirming rather than assuming.

System.out.println(true || false ? 1 : 2);
// 1

That is 1 because the condition parsed as (true || false) ? 1 : 2, which is true, so it yields 1. Adding the parentheses makes the grouping explicit and costs nothing.

int a = 5, b = 3;
int c = 9;
System.out.println(a > b ? a : b);
// 5
System.out.println((a > b ?(a > c ? a : c) :(b > c ? b : c)));
// 9, nested

Nesting a ternary inside the branches is legal and each nested one acts as the condition of the next, so a three-way maximum needs no if statement. Resist it beyond two levels though, because a nested ternary is harder to read than the equivalent if and the compiler will not help.

From Java 16 you can bind a value in the instanceof test itself, and that is where short-circuiting becomes essential rather than merely useful. Without &&, the bound variable would not exist yet in the next condition.

Object o = "hello";
if (o instanceof String s && s.length() > 0) {
    System.out.println(s.length());
    // 5
}

If o were an Integer, instanceof String would be false, the && would stop, and s.length() would never be evaluated on a variable that does not exist. Writing s.length() > 0 without the guard does not compile, because s is only in scope in the true branch of the test.

Object p = 42;
if (p instanceof Integer n && n > 10) {
    System.out.println("n > 10 : " + n);
} else {
    System.out.println("the condition was false, so the else branch runs");
}

Note that with n bound to 42 the test n > 10 is true, so the first branch runs. Swap in a value of 5 and the guard still protects you, and the else runs instead. The pattern is always safe regardless of the runtime type.

The string comparison trap is the one that catches even experienced Java developers, because == on two objects compares references, not contents.

Integer i1 = 100, i2 = 100;
System.out.println(i1 == i2);
// true, both come from the Integer cache
Integer i3 = 1000, i4 = 1000;
System.out.println(i3 == i4);
// false, outside the cache range
System.out.println(i3.equals(i4));
// true, the correct comparison

The wrapper cache covers -128 to 127, so small values appear to work by accident. And the XOR trick from the bitwise topic does not rescue you here, because XOR compares the numeric values and ignores the distinction between a cached and a fresh object entirely.

System.out.println((i3 ^ i4) == 0);
// true, even though i3 == i4 is false

Short-circuiting is one of the highest value ideas in the language, because it is not just an optimisation. It is the mechanism that lets you write a cheap, safe check in front of an expensive, dangerous one, which is why guard clauses read so well. Master the null guard, keep the cheap test on the left, and remember that && binds tighter than ||.