API, ради которых наконец-то стоит обновиться с Java 8. Часть 2

Никогда

Вообще-то в багтрекере OpenJDK и рассылке много обсуждали, сделать ли цикл for для Stream: bugs.openjdk.java.net/browse/JDK-8148917

API, ради которых наконец-то стоит обновиться с Java 8. Часть 2

Пример выше может бы и не сломал много кода, потому что так очень редко кто делает, но вот такой код точно сломается много у кого:

ByteArrayOutputStream baos = new ByteArrayOutputStream();
try {
    baos.write(bytes);
} catch (IOException ex) {
}

Если у write убрать IOException, то catch больше не будет компилироваться.

API, ради которых наконец-то стоит обновиться с Java 8. Часть 2

Потому что это сломало бы код у тех, кто пишет так:

class MyBAOS extends ByteArrayOutputStream {
    @Override
    public void write(byte[] b) throws IOException {
        // код, который может кинуть IOException
    }
}

API, ради которых наконец-то стоит обновиться с Java 8. Часть 2

Predicate.not и Optional.isEmpty появились одновременно в Java 11, поэтому в данном случае not не даёт погоды. Но в других случаях, да, он может быть полезен, например: not(Collection::isEmpty).

API, ради которых наконец-то стоит обновиться с Java 8. Часть 2

Спасибо, это важное замечание. Исправил.

API, ради которых наконец-то стоит обновиться с Java 8. Часть 2

Если переписать на Stream, то придётся ловить IOException. В этом то и проблема.

API, ради которых наконец-то стоит обновиться с Java 8. Часть 2

Если переписать на Stream, то придётся ловить IOException. В этом то и проблема.

API, ради которых наконец-то стоит обновиться с Java 8. Часть 2

Это очень актуально, особенно после новости, что прекращена поддержка Windows 7:)
Или это был троллинг?

API, ради которых наконец-то стоит обновиться с Java 8. Часть 2

Какую фичу?

API, ради которых наконец-то стоит обновиться с Java 8. Часть 2

И какую проблему это решит? А что после peek будет?

Java Records (JEP 359)

и

Java-дайджест за 28 января

Подпишитесь на Телеграм-канал, тогда проверять не надо будет.

API, ради которых наконец-то стоит обновиться с Java 8. Часть 1

Если уж приводить пример, надо показывать действительно то, что не будет выглядеть на столько бессмысленным.

Ну ёлы-палы, добавьте пару операций к стриму, и он сразу же станет смысленным. Ну, так, например:

System.out.println(IntStream
    .iterate(1, i -> i < 100, i -> i * 2)
    .mapToObj(Integer::toString)
    .collect(Collectors.joining(", "))); // 1, 2, 4, 8, 16, 32, 64

А с циклом for то же самое будет уже сильно сложнее.

API, ради которых наконец-то стоит обновиться с Java 8. Часть 1

Да, согласен, это слабенько. Потому что ничего кроме этих 10 методов в новых версиях Java не появилось.
--sarcasm mode off--
Откройте вы уже список JEP'ов в начале статьи и посмотрите, что добавилось.

API, ради которых наконец-то стоит обновиться с Java 8. Часть 1

List.set() будет работать

API, ради которых наконец-то стоит обновиться с Java 8. Часть 1

В Котлине не все методы из списка есть

API, ради которых наконец-то стоит обновиться с Java 8. Часть 1

"Я это не использую, значит оно не нужно"

API, ради которых наконец-то стоит обновиться с Java 8. Часть 1

Любопытно будет посмотреть, как вы самостоятельно будете писать Process.pid или Cleaner :)

API, ради которых наконец-то стоит обновиться с Java 8. Часть 1

Неэффективно будет. takeWhile остановится сразу, а filter будет идти до самого конца.

API, ради которых наконец-то стоит обновиться с Java 8. Часть 1

Аналог Arrays.asList() для Set не нужен, всегда можно передать результат Arrays.asList в конструктор HashSet. Чаще всего такая инициализация востребована в статических константах, а значит лишняя аллокация не имеет значения.

Ну то есть вы предлагаете писать так?

Set<String> set = Collections.unmodifiableSet(new HashSet<>(Arrays.asList("a", "b", "c")));

Очень удобно, ничего не скажешь.

так что на killer-фичу, заставляющую обновляться даже близко не подходит

Где я утверждал, что это киллер-фича? Вы взяли из списка наименее востребованные функции, и сделали вывод, что мигрировать не нужно. А остальные функции проигнорировали. Что скажете по поводу ProcessHandle, takeWhile, Cleaner? Почему вы делаете суждения исходя из востребованности каждой отдельной функции, а не их в совокупности? А почему вы проигнорировали тот факт, что это лишь первая часть? Будут ещё статьи и будет ещё много API.