interfaces - Predicado Java 8 incorporado que siempre devuelve verdadero?

lambda stream java

Question

Google Guava tiene un predicado que siempre devuelve true . ¿Java 8 tiene algo similar para su Predicate ? Sé que podría usar (foo)->{return true;} , pero quiero algo prefabricado, análogo a Collections.emptySet() .

Answer 1

No hay predicados integrados siempre verdaderos y siempre falsos en Java 8. La forma más concisa de escribirlos es

x -> true

y

x -> false

Compare estos con

Predicates.alwaysTrue() // Guava

y finalmente a una clase interna anónima:

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

Probablemente, la razón por la que Guava tiene estos predicados incorporados es que existe una gran ventaja sintáctica de una llamada de método estático sobre una clase interna anónima. En Java 8, la sintaxis lambda es tan concisa que existe una desventaja sintáctica al escribir una llamada a un método estático.

Sin embargo, eso es solo una comparación sintáctica. Probablemente haya una pequeña ventaja de espacio si hubiera un solo predicado global siempre verdadero, en comparación con x -> true ocurrencias x -> true distribuidas en múltiples clases, cada una de las cuales crearía su propia instancia de predicado. ¿Es esto lo que te preocupa? Los ahorros no parecían convincentes, por lo que probablemente no se agregaron en primer lugar. Pero podría reconsiderarse para un lanzamiento futuro.

ACTUALIZACIÓN 24/04/2015

Hemos considerado la adición de una variedad de funciones estáticas con nombre, como Predicate.alwaysTrue , Runnable.noop , etc., y hemos decidido no agregar más en futuras versiones de Java SE.

Ciertamente, hay algo de valor en algo que tiene un nombre frente a una lambda escrita, pero este valor es bastante pequeño. Esperamos que las personas aprendan a leer y escribir x -> true y () -> { } y que su uso se vuelva idiomático. Incluso el valor de Function.identity() sobre x -> x es cuestionable.

Existe una pequeña ventaja de rendimiento al reutilizar una función existente en lugar de evaluar una lambda escrita, pero esperamos que el uso de este tipo de funciones sea tan pequeño que dicha ventaja sería insignificante, ciertamente no vale la pena el aumento de API.

Holger también mencionó en los comentarios la posibilidad de optimizar funciones compuestas como Predicate.or y tales. Esto también se consideró ( JDK-8067971 ), pero se consideró algo frágil y propenso a errores, y ocurría con poca frecuencia que no valía la pena implementarlo.

Consulte también esta entrada de Preguntas frecuentes de Lambda .

Answer 2

Sin guayaba

Boolean.TRUE::booleanValue