it-roy-ru.com

Встроенный предикат Java 8, который всегда возвращает true?

В Google Guava есть предикат, который всегда возвращает true . У Java 8 есть что-то похожее для его Predicate? Я знаю, что могу использовать (foo)->{return true;}, но я хочу что-то заранее приготовленное, аналогично Collections.emptySet().

111
Garret Wilson

В Java 8. нет встроенных предикатов "всегда истинно" и "всегда ложно". Наиболее краткий способ их записи:

x -> true

а также

x -> false

Сравните это с

Predicates.alwaysTrue() // Guava

и, наконец, анонимный внутренний класс:

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

Вероятно, причина того, что у Guava есть эти встроенные предикаты, заключается в том, что существует огромный синтаксический плюс вызова статического метода перед анонимным внутренним классом. В Java 8 лямбда-синтаксис настолько лаконичен, что имеет синтаксический недостаток для записи статического вызова метода.

Это всего лишь синтаксическое сравнение. Вероятно, есть небольшое преимущество в пространстве, если бы существовал один глобальный всегда истинный предикат по сравнению с x -> true вхождениями, распределенными по нескольким классам, каждый из которых создал бы свой собственный экземпляр предиката. Это то, что тебя беспокоит? Экономия не выглядела убедительной, и, вероятно, именно поэтому они не были добавлены в первую очередь. Но это может быть пересмотрено для будущего выпуска.

ОБНОВЛЕНИЕ 2015-04-24

Мы рассмотрели добавление множества статических именованных функций, таких как Predicate.alwaysTrue, Runnable.noop и т.д., И решили не добавлять больше в будущих версиях Java SE.

Конечно, есть нечто в чем-то, что имеет имя, а не в выписанной лямбде, но это значение довольно мало. Мы ожидаем, что люди научатся читать и писать x -> true и () -> { } и что их использование станет идиоматическим. Даже значение Function.identity() по сравнению с x -> x сомнительно.

Есть небольшое преимущество в производительности, заключающееся в повторном использовании существующей функции вместо оценки выписанной лямбды, но мы ожидаем, что использование этих видов функций будет настолько малым, что такое преимущество будет незначительным и, конечно, не будет стоить API.

Хольгер также упомянул в комментариях возможность оптимизации составных функций, таких как Predicate.or и тому подобное. Это также рассматривалось ( JDK-8067971 ), но считалось несколько хрупким и подверженным ошибкам, и происходило достаточно редко, чтобы его реализация не стоила усилий.

Смотрите также эту Lambda FAQ запись.

142
Stuart Marks

Без гуавы

Boolean.TRUE::booleanValue
4
boriselec