Java Predicate Interface

Predicate<T> is the functional interface for a single-argument condition that returns true or false. It exists because so much everyday code reduces to the same shape — does this value satisfy some rule — and writing a brand new interface every time that pattern shows up would be needless repetition. Java 8 shipped Predicate<T> in java.util.function with exactly one abstract method, test(T t), alongside a handful of default methods that let several predicates combine into a bigger rule without any of them changing.

What Is Predicate?

Predicate<T> declares boolean test(T value) as its single abstract method, which makes it a valid target for any lambda or method reference that takes one argument of type T and returns a boolean. It also carries default methods — and, or, negate — and a couple of static ones — not, isEqual — that exist specifically to combine predicates without writing a bigger, more tangled condition by hand.

It shows up constantly wherever Java code needs to ask "does this qualify" — Stream.filter(), Collection.removeIf(), and any method you write that accepts a reusable condition as a parameter instead of a single hardcoded check.

Why Predicate Was Introduced

Before Java 8, a filtering rule lived inside a loop, checked with a plain if statement, with no way to hand that rule to another method or reuse it somewhere else without copying the condition itself.

Output:
[320, 150, 600]

The same rule expressed as a Predicate<Integer> becomes a value on its own — something that can be passed to filter, stored in a variable, reused across several methods, and combined with other rules later without ever touching the loop that consumes it.

Output:
[320, 150, 600]

The output is identical either way. What changed is that meetsMinimum is now a named, reusable value instead of logic buried inside one loop.

Syntax

Predicate<T> combines one abstract method with default methods for boolean composition and static methods for two common patterns.

Output:
4 positive and even: true
3 positive and even: false
-4 positive or even: true
-3 positive or even: false
-3 not positive: true
7 not even (static): true
isEqual 5 against 6: false

Common Use Cases

Filtering a Stream

Stream.filter is the single most common place a Predicate appears in real code, keeping the filtering rule readable as a named value instead of an inline expression buried inside the pipeline.

Output:
[Laptop, Keyboard, Monitor]

Removing Elements That Match a Condition

Collection.removeIf takes a Predicate directly and removes every matching element in place, which reads more clearly than a manual iterator loop written to avoid a ConcurrentModificationException.

Output:
[120, 45, 300]

Combining Smaller Rules Into a Bigger One

and() builds a stricter condition out of two smaller ones, and it short-circuits exactly the way the && operator does — the second predicate never runs once the first has already returned false.

Output:
Password123 is strong: true
weak is strong: false

Accepting a Predicate as a Reusable Rule

Passing a Predicate into a method turns that method into something generic and reusable, instead of hardcoding one specific condition it can never be used for again.

Output:
Adults: 3

Real-World Example

A food delivery platform typically has to check several unrelated conditions before an order is confirmed as deliverable — is the customer within the service radius, is the restaurant currently open, does the order meet the minimum amount, and is the customer blacklisted. Writing all four checks inline inside one method makes that method grow every single time a new business rule shows up. Declaring each condition as a named Predicate and combining them with and, or, and not keeps every rule readable, testable, and reusable on its own.

Output:
ORD-1 eligible: true
ORD-2 eligible: false
ORD-3 eligible: false
ORD-1 free delivery: false
ORD-4 free delivery: true

Reading isEligibleForDelivery top to bottom in EligibilityRules tells you exactly what qualifies an order without opening a single method body — each rule already carries a name that says what it checks. A mistake that appears often in fresher pull requests is folding all four of these checks back into one long if condition inside EligibilityChecker the moment a fifth rule needs adding, which quietly throws away the entire readability benefit this design was built for.

Combining Predicate With Other Features

Predicate composes naturally with Stream.filter and Collection.removeIf, and its and, or, and negate methods let a handful of small, well-named predicates build up into a rule as complex as an entire eligibility check without ever declaring a new interface. Method references pair especially well with Predicate for simple property checks, exactly as DeliveryOrder::isRestaurantOpen does above. For a condition that needs two arguments instead of one, BiPredicate<T, U> fills the same role with an extra parameter.

Best Practices

Give every meaningful predicate a name, the way withinServiceArea and restaurantIsOpen are named above, rather than inlining the condition directly into filter or an if statement. A named predicate reads like a line of documentation the next time someone opens the file.

Reach for Predicate.not() when negating a bare method reference, since a method reference has no negate() method to call until the compiler has already resolved it into a Predicate. negate() still works fine on an existing Predicate variable — the static form exists specifically for the method reference case.

Keep test() free of side effects. A predicate should only answer a question about the value it receives, never mutate that value, a shared field, or anything else — a predicate with side effects behaves unpredictably the moment it runs inside a parallel stream or gets evaluated more than once.

Common Mistakes

Calling .negate() directly on a bare method reference does not compile, because a method reference has no methods of its own until it has already been resolved into a Predicate.

Output:
BLOCKED-1 allowed: false
CUST-99 allowed: true

Chaining and() and or() without thinking about grouping produces a different result than most people expect, because each call combines strictly left to right rather than following any implicit "and binds tighter than or" rule the way Java's && and || operators do.

Output:
chainedLeftToRight.test(50): false
chainedDifferently.test(50): true

A predicate that quietly captures mutable state, such as a counter incremented inside test(), stops being safely reusable the moment it runs inside a parallel stream or gets called from more than one place at the same time. This mistake rarely shows up in a single-threaded test locally, which is exactly why it tends to survive code review and surface later as an intermittent production bug instead.

Interview Questions

Q1. What is Predicate in Java, and where does it fit in java.util.function?

Predicate<T> is the functional interface for a single-argument condition that returns a boolean, declaring test(T value) as its one abstract method. It belongs to the java.util.function package alongside Function, Consumer, and Supplier, and it is the interface behind every lambda passed to Stream.filter or Collection.removeIf. Interviewers commonly use this as a warm-up question to confirm the candidate can connect the interface name to its actual method signature rather than describing it only in the abstract.

Q2. What is the difference between Predicate.negate() and Predicate.not()?

negate() is an instance method called on an already-existing Predicate, returning a new predicate that inverts its result. Predicate.not() is a static method, added in Java 11, that does the same inversion but accepts a method reference or lambda directly, before it has been assigned to a Predicate variable — this matters because a bare method reference has no negate() method of its own to call.

Q3. Do and() and or() short-circuit the way the && and || operators do?

Yes. and() stops evaluating and returns false as soon as the first predicate returns false, and or() stops and returns true as soon as the first predicate returns true — the second predicate in each case never runs once the outcome is already decided. This matters in practice whenever the second predicate is more expensive to evaluate or depends on state the first predicate is responsible for validating first.

Q4. How would you combine three or more predicates while controlling evaluation order explicitly?

Chain and() and or() calls in the exact order the logic requires, using parentheses around sub-expressions the same way you would with boolean operators, since Predicate composition has no implicit operator precedence of its own — each call simply combines with whatever came immediately before it. Product-based interviews often follow up by asking the candidate to trace through a chained expression like a.or(b).and(c) versus a.or(b.and(c)) to confirm they understand the grouping is entirely explicit, not inferred.

Q5. What is the difference between Predicate and BiPredicate?

Predicate<T> tests a single argument through test(T value), while BiPredicate<T, U> tests two arguments of potentially different types through test(T first, U second) — comparing two values against each other, for example, rather than checking one value against a fixed rule. Both interfaces expose the same and, or, and negate default methods for combining rules.

Q6. Can a Predicate maintain state across multiple test() calls, and is that good practice?

Technically yes, since nothing prevents a lambda from capturing and mutating an outside variable or an instance field inside test(), but it is considered poor practice because it breaks the assumption that a predicate is a pure, repeatable check. A stateful predicate produces different results for the same input depending on when it runs, which becomes especially dangerous inside a parallel stream where multiple threads may call test() concurrently on the same predicate instance.

FAQs

Can Predicate be used with primitives directly?

Not without autoboxing. Predicate<Integer> boxes every int into an Integer before testing it, which is fine for most everyday code, but java.util.function also ships IntPredicate, LongPredicate, and DoublePredicate specifically to avoid that boxing cost when it matters.

What is Predicate.isEqual used for?

Predicate.isEqual(target) builds a predicate that checks whether its input equals a fixed target object, using Objects.equals internally so it also handles null safely. It is most often used inside filter() when the condition is a simple equality check against one known value, rather than a custom comparison rule.

Is Predicate the same as a boolean-returning Function?

Conceptually similar but not interchangeable. Function<T, Boolean> returns a boxed Boolean and has no and, or, or negate methods, while Predicate<T> returns a primitive boolean and ships with all three composition methods built in specifically for combining conditions.

Can I chain more than two predicates together?

Yes, without any limit. Each call to and() or or() returns a new Predicate, so chaining a.and(b).and(c).and(d) combines any number of conditions, one call at a time, in the exact order they are written.

Does filter() with a Predicate create a new list immediately?

No. Stream.filter is a lazy, intermediate operation — nothing runs until a terminal operation like collect or forEach is called on the stream, at which point the predicate is evaluated once per element as the stream actually processes them.

Can a Predicate be null-safe by default?

No, and this trips up plenty of beginners. Calling test(null) runs whatever logic the predicate's body contains against null, and it throws a NullPointerException the moment that body tries to call a method on the null value — the predicate itself does not add any automatic null handling.

What is IntPredicate and why does it exist?

IntPredicate is the primitive-specialized version of Predicate<Integer>, declaring test(int value) instead of test(Integer value). It exists purely to avoid the autoboxing cost of wrapping every int into an Integer object, which matters most in performance-sensitive code processing large volumes of primitive values.

Summary

Predicate<T> gives every "does this qualify" check in your codebase a shared, reusable shape instead of a fresh if statement written from scratch each time. test() asks the question, and and, or, negate, and not let several small, well-named predicates build into a bigger rule without any of the smaller ones changing — exactly the pattern the delivery eligibility example leans on.

The two things worth carrying forward are that predicate chaining is always evaluated strictly in the order it is written, with no implicit precedence to rely on, and that a predicate should stay a pure check with no side effects, since that purity is what makes it safe to reuse anywhere in the codebase without surprises. Function, Consumer, and Supplier follow the exact same design instincts from here, just answering different questions than "true or false."

What to Read Next