Un prédicat Java 8 intégré qui renvoie toujours true?

Google Guava a un prédicat qui renvoie toujours true . Java 8 a-t-il quelque chose de similaire pour son Predicate ? Je sais que je pourrais utiliser (foo)->{return true;} , mais je veux quelque chose de prédéfini, analogue à Collections.emptySet() .

Il n’existe pas de prédicats intégrés toujours vrais et toujours faux dans Java 8. Le moyen le plus concis pour les écrire est

 x -> true 

et

 x -> false 

Comparez ces pour

 Predicates.alwaysTrue() // Guava 

et enfin à une classe interne anonyme:

 new Predicate() { public boolean test(Object x) { return true; } } 

La raison pour laquelle Guava possède ces prédicats intégrés est probablement qu’il ya un énorme avantage syntaxique d’un appel de méthode statique sur une classe interne anonyme. Dans Java 8, la syntaxe lambda est si concise qu’il ya un inconvénient syntaxique à écrire un appel de méthode statique.

C’est juste une comparaison syntaxique, cependant. Il y a probablement un petit avantage spatial s’il y avait un seul prédicat global toujours vrai, par rapport à x -> true occurrences x -> true réparties sur plusieurs classes, chacune d’entre elles créerait sa propre instance de prédicat. Est-ce ce qui vous préoccupe? Les économies n’ont pas semblé 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 envisagé d’append une variété de fonctions statiques nommées telles que Predicate.alwaysTrue , Runnable.noop , etc., et nous avons décidé de ne plus en append dans les futures versions de Java SE.

Certainement, il y a une certaine valeur dans quelque chose qui a un nom contre un lambda écrit, mais cette valeur est assez petite. Nous espérons que les utilisateurs apprendront à lire et à écrire x -> true et () -> { } et que leur utilisation deviendra idiomatique. Même la valeur de Function.identity() sur x -> x est discutable.

La réutilisation d’une fonction existante au lieu d’évaluer un lambda écrit présente un avantage minime sur le plan des performances, mais nous pensons que l’utilisation de ces fonctions sera si faible qu’un tel avantage serait négligeable, sans aucun doute pour l’inflation de l’API.

Holger a également mentionné dans les commentaires la possibilité d’optimiser des fonctions composées telles que Predicate.or et autres. Cela a également été envisagé ( JDK-8067971 ), mais a été jugé quelque peu fragile et sujet aux erreurs, et se produisant assez rarement pour que cela ne vaille pas la peine d’être mis en œuvre.

Voir aussi cette FAQ Lambda .

Sans goyave

 Boolean.TRUE::booleanValue