Является ли Java 8 необязательным?

Ответ 1

В этой цитате объясняются соображения, лежащие в основе примитивных потоков. Я принимаю то же самое применимо к примитивным опциям. Короче говоря, примитивные потоки (и, вероятно, Опционы также) были созданы по соображениям производительности. Они не создавали их для всех 8 примитивных типов, чтобы уменьшить дублирование кода и загрязнение интерфейса.

Цитируя слова Брайана Гетца в список рассылки лямбда:

В более общем плане: философия за примитивные потоки (например, IntStream) чреваты неприятными компромиссами. С одной стороны, это много уродливого дублирования кода, интерфейса загрязнение и т.д. С другой стороны, любая арифметика на бокс-операциях отстой, и отсутствие истории для сокращения по сравнению с ints было бы ужасно. Поэтому мы находимся в сложном уголке, и мы стараемся не ухудшать ситуацию.

Трюк №1 за то, что он не усугубляет ситуацию: мы не делаем все восемь примитивных типов. Мы делаем int, long и double; все остальные могут имитироваться. Возможно, мы могли бы избавиться от int тоже, но мы не считаем, что большинство разработчиков Java готовы к этому. Да будут вызовы для символа, и ответ "вставьте его в int". (Каждая специализация проецируется на ~ 100K на след JRE.)

Trick # 2: мы используем примитивные потоки, чтобы выставлять вещи, которые лучше всего делать в примитивном домене (сортировка, сокращение), но не пытаясь дублировать все, что вы можете сделать в коробке домена. Для Например, нет IntStream.into(), как указывает Алексей. (Если здесь были, следующий вопрос был бы "Где IntCollection? IntArrayList? IntConcurrentSkipListMap?) Намерение - это много потоков могут начинаться как ссылочные потоки и заканчиваться как примитивные потоки, но не наоборот. Это нормально, и это уменьшает количество конверсий (например, отсутствие перегрузки карты для int → T, отсутствие специализации Функция для int → T и т.д.)

И я должен упомянуть, что я нашел эту цитату в ответе на этот вопрос.

Ответ 2

boolean часто используются в качестве параметров. Эффективное Java 2nd edition предупреждает о злоупотреблении логическими данными. Они часто приводят к плохо читаемому коду, если они не соответствуют фактическим логическим аргументам true/false. Вместо этого Джошуа Блох - писатель - пытается убедить людей использовать двойные значения enum:

Предпочитают двухэлементные enum типы boolean. Это упрощает чтение и запись кода, особенно если вы используете среду IDE, которая поддерживает автозаполнение. Также он упрощает добавление дополнительных опций позже.

Большинство экземпляров OptionalBoolean, вероятно, будут использоваться неправильно. Это хорошая причина не включать его. Но я не могу сказать - только Oracle может - если это причина, по которой его там нет.

Ответ 3

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

Причина того, почему преимущество меньше, состоит в том, что существует только два разных значения типа boolean. Из-за этого большую часть времени вы получаете только два объекта типа boolean. Эти два кэшируются как Boolean.TRUE и Boolean.FALSE и повторно используются в большинстве случаев, например. когда boolean автоматически блокируются. Числовые типы обертки имеют несколько кешированных объектов для небольшого диапазона значений, для других значений новый объект должен быть назначен каждый раз, когда примитивное значение хранится в общем контейнере, таком как Optional.

Таким образом, объект Optional<Boolean> работает почти так же эффективно, как и OptionalBoolean, так как не нужно выделять новый boolean для размещения в него unboxed boolean.

Я также мог бы быть полезен, если бы в стандартной библиотеке было доступно два обходимых Optional<Boolean>, возможно, как Optional.TRUE/FALSE. Я не знаю причины, почему этого не происходит.

Ответ 4

Просто для того, чтобы быть полным: в Java 8 действительно есть OptionalBoolean, но не там, где вы ожидали бы: это com.sun.javafx.scene.control.behavior.OptionalBoolean.

Но, хотя JavaFX в настоящее время является фиксированным компонентом Java, нецелесообразно использовать его вне JavaFX.

Кроме того, его интерфейс полностью отличается от того, который у вас есть в java.util.*.