Google Guava has a predicate that always returns true
. Does Java 8 have something similar for its Predicate
? I know I could use (foo)->{return true;}
, but I want something pre-made, analogous to Collections.emptySet()
.

- 127,867
- 37
- 205
- 259

- 18,219
- 30
- 144
- 272
3 Answers
There are no built-in always-true and always-false predicates in Java 8. The most concise way to write these is
x -> true
and
x -> false
Compare these to
Predicates.alwaysTrue() // Guava
and finally to an anonymous inner class:
new Predicate<Object>() {
public boolean test(Object x) {
return true;
}
}
Probably the reason that Guava has these built-in predicates is that there is a huge syntactic advantage of a static method call over an anonymous inner class. In Java 8, the lambda syntax is so concise that there is a syntactic disadvantage to writing out a static method call.
That's just a syntactic comparison, though. There is probably a small space advantage if there were a single global always-true predicate, compared to x -> true
occurrences spread across multiple classes, each of which would create its own predicate instance. Is this what you're concerned about? The savings didn't seem compelling, which is probably why they weren't added in the first place. But it could be reconsidered for a future release.
UPDATE 2015-04-24
We've considered the addition of a variety of static, named functions such as Predicate.alwaysTrue
, Runnable.noop
, etc., and we have decided not to add any more in future versions of Java SE.
Certainly there is some value in something that has a name vs. a written-out lambda, but this value is quite small. We expect that people will learn how to read and write x -> true
and () -> { }
and that their usage will become idiomatic. Even the value of Function.identity()
over x -> x
is questionable.
There is a tiny performance advantage to reusing an existing function instead of evaluating a written-out lambda, but we expect the usage of these kinds of functions to be so small that such an advantage would be negligible, certainly not worth the API bloat.
Holger also mentioned in comments the possibility of optimizing composed functions such as Predicate.or
and such. This was also considered (JDK-8067971) but was deemed somewhat fragile and error-prone, and occurring infrequently enough that it wasn't worth the effort to implement.
See also this Lambda FAQ entry.

- 127,867
- 37
- 205
- 259
-
22Two concerns: The first is brevity. If `(foo)->{return true;}` is the best I can do, I want better. But you brought up `x->true`, which is much better and mitigates the first issue. The second issue is of logic vs static declaration. If I use `x->true`, there is still logic involved, which I could inadvertently screw up (e.g. `x->!true`). But with `Predicate.alwaysTrue()`, there is zero room for logic error, as there are only one or two similar methods. Plus I get IDE code completion for free. `x->true` is almost fine, but I still wrote a `Predicate.alwaysTrue()` method for the reasons above. – Garret Wilson Oct 24 '14 at 23:54
-
12@GarretWilson But with `Predicate.alwaysTrue()` you could also screw up by accidentally writing `Predicate.alwaysFalse()`. – David Conrad Oct 25 '14 at 01:26
-
7@DavidConrad, of course. There are always ways I can make mistakes, and in fact I'm constantly inventing new ones. ;) I don't want to start an argument here over something trivial, but I'll just say that my point is that with a static method reference I have a constrained vocabulary with only two choices: `alwaysTrue()` and `alwaysFalse()`. With the actual lambda, I have many variations; I am essentially reconstructing the formula each time. In essence, `alwaysTrue()` is a semantic label for what I want to do; `x->true` is actually doing it over again each time. Not huge, but a consideration. – Garret Wilson Oct 25 '14 at 01:33
-
2@GarretWilson Sure, naming things is good. For similar reasons we have `Integer::sum` as an alternative to `(a,b) -> a + b`. – Stuart Marks Oct 25 '14 at 18:04
-
1@StuartMarks, I'm accepting your answer as the correct one; "no" is the correct answer to my specific yes/no question, I suppose. ;) But seriously, the suggestion of `x->true` is very useful; I had forgotten the ultra-short form. Thanks. – Garret Wilson Oct 25 '14 at 21:40
-
@GarretWilson what do you mean by _screw up the logic_? You could create `final static Predicate isTrue = x -> true;` and then just use it e.g. `xyz.stream().filter(isTrue)...`? – ifloop Oct 26 '14 at 01:51
-
@ifLoop, by "screw up the logic" I mean that if I'm typing the actual logic, I might enter `x->!true` or some variation, because I'm typing out the logic itself, not a label. Yes, I could create a static constant myself, which would be just such a "label"; but this question was simply whether Java already has such a "labeled" predicate ready for use. The answer is "no", I have to make one myself. – Garret Wilson Oct 26 '14 at 15:09
-
30One big advantage of canonical `Predicate.alwaysTrue()` and `Predicate.alwaysFalse()` instances is, that they could be recognized by combining methods like `Predicate.or`, `Predicate.and`, and `Predicate.negate()`. This would allow to pre-initialize `Predicate` variables with `alwaysTrue()` and add predicates by combining via `and` without overhead. Since lambda expressions have no object identity guaranty, this might fail with `x->true`. By the way, if I have a class `X` with a `static` method `y(){return true;}`, using `X::y` is even shorter than `x->true` but not really recommended… – Holger Oct 27 '14 at 10:45
-
Class Boolean could be extended with methods true(Object) and false(Object) and then you could write Boolean::true or Boolean::false (expanding on @Holger's idea), but that doesn't seem compelling next to x->true / x->false. (BTW, I like writing ....map("prefix-"::concat)... and just wish there was a String::rconcat as well. I like method references that bind a particular object. That's not what Boolean::true(Object) and Boolean::false(Object) would be, of course.) – davidbak Aug 19 '15 at 17:38
-
17The idiom `x -> true` has the disadvantage that I have to use a variable without use. This creates unnecessary brain load and also a warning in my IDE. I tried to use `_ -> true`, but that is a syntax error. Java is definitely missing a keyword (read: keyletter) for "unused parameter". Hope that something like this will come in Java 9 (or at least: Java whatever before I die ^^) – kap Nov 10 '15 at 21:27
-
2@StuartMarks: "...we have decided not to add any more in future versions of Java SE." In the light of `Function.identity()` as `t -> t`, it seems odd that `t -> true` is so bad. I understand the sentiment of "we're tired of adding things", but don't throw consistency and completeness out the door. I don't want to Java to become a hodgepodge of arbitrary things that got in or out. It worries me a bit that so many things were left out of Java 8 because "we didn't want to add any more", such as `Optional` being `Serializable` or `CharStream`. Just some musings and feedback on things I encounter. – Garret Wilson Jul 04 '16 at 15:41
-
2@GarretWilson If I gave the impression "we're tired of adding things" then that was mistaken. There was a whole list of potential methods on functional interfaces that we considered adding. There was a deliberate judgment call in a team discussion that adding them didn't produce enough benefit to justify the effort. The tradeoffs are clearer with things like `CharStream`; the amount of almost-duplicate code that would be required considerably outweighs the amount of use it (and other primitive streams) would get. – Stuart Marks Jul 09 '16 at 00:41
-
1@GarretWilson `Optional` not being `Serializable` was on the other hand a deliberate design decision to keep the compatibility "surface area" of `Optional` to a minimum; having a serial form increases that surface area considerably. That would potentially add risk to the eventual transition of `Optional` to be a value type, work which is still ongoing. – Stuart Marks Jul 09 '16 at 00:44
-
1guava's version is `Predicates.alwaysTrue()`, not `Predicate.alwaysTrue()` – jaudo Nov 08 '16 at 14:09
-
5@kap My teams convention for unsused lambda variables has become `__ -> true` (two underscores), which is a valid Java identifier. You can teach your IDE to accept certain names. – Oliver Jan Krylow Feb 22 '17 at 10:41
-
@Holger Yes it would be a performance advantage to recognize canonical constants in `and`/`or`/etc, but as low-performance as streams are, it's negligible. Moreover, if you want performance, you shouldn't use object streams in the first place. They were introduced to trade speed for readability. – Mark Jeronimus Jul 09 '17 at 10:27
-
In some cases, an unused parameter can have a good semantic name. Usually, I prefer the style `anyValue -> true`, `anyConsumer -> false`, `ignoredValue -> 0` etc. It's a more unpleasant situation (especally in legacy code bases) when a closure variable and a parameter refers to the same object: `listenable.listen((listenableParam, event) -> foo())`. – Dávid Horváth Nov 18 '20 at 22:26
-
"…we have decided not to add any more in future versions of Java SE. … [W]e expect the usage of these kinds of functions to be so small that such an advantage would be negligible, certainly not worth the API bloat." Stuart Marks, I can't say that your reluctance to bloat the API is wrong. However there is another factor: because the user base apparently wants this functionality, now libraries such as Guava and Spring have implemented this redundantly, so now codebases, instead of being standardized are split among multiple competing (and bloated) libraries. – Garret Wilson Aug 29 '22 at 16:24
-
For those of us who want to have strongly typed anchors to maximize DRY and facilitate confident refactorings across enormous legacy codebases, we resort to creating things like this: https://stackoverflow.com/a/76985309/501113 – chaotic3quilibrium Aug 28 '23 at 17:47
In case you are looking for this in Spring framework:
org.springframework.data.util.Predicates
supports this.
Predicates.isTrue()
, Predicates.isFalse()

- 8,967
- 3
- 49
- 55
-
5That's interesting. I'm not sure if it completely captures the spirit of the request, but it gets points for creativity! – Garret Wilson Oct 21 '17 at 01:16
-
36
-
2It's not a predicate, it's a method reference but it has the merit of being concise and not forcing to mention an unused parameter. +1 By the way, as it avoids to use Guava which has a serious problem of modularity, it deserves my upvote ;) – gouessej Feb 20 '18 at 16:57
-
35
-
6People: **please stop upvoting this!** This answer is **plain incorrect**. You **cannot** write `Predicate
p = Boolean.TRUE::booleanValue` because `booleanValue()` does not take any argument. You could merely use it as `Supplier – Didier L Feb 07 '22 at 19:35` (as Daniel says), which does not answer the question (and is probably rarely useful).