Demonstrate Short-Circuit AND in Java
Problem
The && operator short-circuits: if the left operand is false, the overall result is already determined to be false, so Java never bothers evaluating the right operand at all — not even to compute a value it would then discard.
Given a false left-hand condition, prove that the right-hand side of && is never evaluated at all.
Java Program
public class DemonstrateShortCircuitAnd {
static boolean rightSide() {
System.out.println("Right side evaluated!");
return true;
}
public static void main(String[] args) {
boolean left = false;
System.out.println("Evaluating: left && rightSide()");
boolean result = left && rightSide(); // rightSide() is never called, since left is already false
System.out.println("Result: " + result);
}
}Output
Core Logic
Putting a visible print statement inside the right-hand method makes short-circuiting provable, not just theoretical — if that print never appears, the method genuinely never ran.
- 1
rightSide()prints a message before returningtrue, so if it's called, that message will show up in the output. - 2
leftisfalse. - 3
left && rightSide()evaluatesleftfirst — since it's alreadyfalse, the whole expression is guaranteed to befalseno matter whatrightSide()would return. - 4Because the result is already decided, Java skips calling
rightSide()entirely — its print statement never runs, which is why"Right side evaluated!"never appears in the output.
left = false, left && rightSide() prints only Result: false — no message from rightSide() at all, proving it was never called.Key Point: Short-circuiting isn't just an optimization — it's something code can safely depend on, such as writing list != null && list.size() > 0, where the second check would throw a NullPointerException if it ran on a null list, but never gets the chance to.
Key Concepts
Approach 2: Java 8
import java.util.function.BooleanSupplier;
public class ShortCircuitAndSupplier {
public static void main(String[] args) {
boolean left = false;
// Nothing inside this lambda runs yet — it's just a stored, deferred computation
BooleanSupplier rightSide = () -> {
System.out.println("Right side evaluated!");
return true;
};
System.out.println("Evaluating: left && rightSide.getAsBoolean()");
boolean result = left && rightSide.getAsBoolean(); // never invoked, since left is false
System.out.println("Result: " + result);
}
}
Output
Core Logic
Wrapping the right-hand side in a BooleanSupplier makes the deferred, maybe-never-run nature of that computation explicit as a value, instead of leaving it implicit in a plain method call.
- 1
BooleanSupplier rightSide = () -> { ...; return true; };packages the same print-then-return logic as a lazy value — nothing inside the lambda runs yet, just by creating it. - 2
left && rightSide.getAsBoolean()still short-circuits exactly the same way as calling a method directly would —&&doesn't care whether its right operand is a plain call or a storedBooleanSupplier. - 3Since
leftisfalse,getAsBoolean()is never invoked, and the lambda's print statement never runs.
left = false, the stored rightSide supplier is created but never invoked — the output is identical to the direct method-call version.Key Point: A BooleanSupplier makes the laziness visible as a value you can pass around, store, or reuse — but it doesn't change the short-circuit behavior itself, which comes from && alone, not from how the right-hand side happens to be written.