Il n'y a pas de prédicats intégrés toujours vrais et toujours faux dans Java 8. La façon la plus concise de les écrire est
x -> true
et
x -> false
Comparez-les à
Predicates.alwaysTrue() // Guava
et enfin à une classe interne anonyme:
new Predicate<Object>() {
public boolean test(Object x) {
return true;
}
}
La raison pour laquelle Guava a ces prédicats intégrés est probablement qu'il y a un énorme avantage syntaxique à un appel de méthode statique par rapport à une classe interne anonyme. Dans Java 8, la syntaxe lambda est si concise qu'il existe un inconvénient syntaxique à l'écriture d'un appel de méthode statique.
C'est juste une comparaison syntaxique, cependant. Il y a probablement un petit avantage d'espace s'il y avait un seul prédicat global toujours vrai, par rapport aux x -> true
occurrences réparties sur plusieurs classes, chacune créant sa propre instance de prédicat. Est-ce cela qui vous préoccupe? Les économies ne semblaient pas convaincantes, ce qui explique probablement pourquoi elles n'ont pas été ajoutées en premier lieu. Mais il pourrait être reconsidéré pour une future version.
MISE À JOUR 2015-04-24
Nous avons considéré l'ajout d'une variété de statique, des fonctions telles que nommées Predicate.alwaysTrue
, Runnable.noop
etc., et nous avons décidé de ne pas ajouter plus dans les futures versions de Java SE.
Il y a certainement une valeur dans quelque chose qui a un nom par rapport à un lambda écrit, mais cette valeur est assez petite. Nous nous attendons à ce que les gens vont apprendre à lire et à écrire x -> true
et () -> { }
et que leur utilisation deviendra idiomatiques. Même la valeur de Function.identity()
over x -> x
est discutable.
Il y a un petit avantage en termes de performances à réutiliser une fonction existante au lieu d'évaluer un lambda écrit, mais nous nous attendons à ce que l'utilisation de ces types de fonctions soit si faible qu'un tel avantage serait négligeable, ne valant certainement pas le gonflement de l'API.
Holger a également mentionné dans les commentaires la possibilité d'optimiser des fonctions composées telles que Predicate.or
et telles. Cela a également été pris en compte ( JDK-8067971 ) mais a été jugé quelque peu fragile et sujet aux erreurs, et se produisant assez rarement pour que la mise en œuvre ne valait pas la peine.
Consultez également cette entrée de la FAQ Lambda .
(foo)->{return true;}
c'est le mieux que je puisse faire, je veux mieux. Mais vous avez évoquéx->true
, ce qui est bien mieux et atténue le premier problème. Le deuxième problème concerne la déclaration logique vs statique. Si j'utilisex->true
, il y a toujours une logique impliquée, que je pourrais bousiller par inadvertance (par exemplex->!true
). Mais avecPredicate.alwaysTrue()
, il n'y a aucune place pour l'erreur logique, car il n'y a qu'une ou deux méthodes similaires. De plus, j'obtiens la complétion du code IDE gratuitement.x->true
c'est presque bien, mais j'ai quand même écrit unePredicate.alwaysTrue()
méthode pour les raisons ci-dessus.