Demonstrate Short-Circuit OR in Java
Problem
The || operator short-circuits: if the left operand is true, the overall result is already determined to be true, so Java never bothers evaluating the right operand at all — not even to compute a value it would then discard.
Given a true left-hand condition, prove that the right-hand side of || is never evaluated at all.
Java Program
public class DemonstrateShortCircuitOr {
static boolean rightSide() {
System.out.println("Right side evaluated!");
return false;
}
public static void main(String[] args) {
boolean left = true;
System.out.println("Evaluating: left || rightSide()");
boolean result = left || rightSide(); // rightSide() is never called, since left is already true
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 returningfalse, so if it's called, that message will show up in the output. - 2
leftistrue. - 3
left || rightSide()evaluatesleftfirst — since it's alreadytrue, the whole expression is guaranteed to betrueno 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 = true, left || rightSide() prints only Result: true — no message from rightSide() at all, proving it was never called.Key Point: This mirrors && short-circuiting on a false left operand — || short-circuits on a true one, which is why cache != null || rebuildCache() is a common pattern: the expensive rebuild only happens when it's actually needed.
Key Concepts
Approach 2: Java 8
import java.util.function.BooleanSupplier;
public class ShortCircuitOrSupplier {
public static void main(String[] args) {
boolean left = true;
// Nothing inside this lambda runs yet — it's just a stored, deferred computation
BooleanSupplier rightSide = () -> {
System.out.println("Right side evaluated!");
return false;
};
System.out.println("Evaluating: left || rightSide.getAsBoolean()");
boolean result = left || rightSide.getAsBoolean(); // never invoked, since left is already true
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 false; };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
leftistrue,getAsBoolean()is never invoked, and the lambda's print statement never runs.
left = true, 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.