В java 23 Stream gatherers, которые появились в Java 22 в режиме preview, остаются на второе preview без изменений. Gatherers - это усовершенствование Stream API для поддержки произвольных промежуточных операций.
если серьезно оценивать, то все примеры в докладе сильно притянуты за уши. все задачи можно решить обычным способом (без стримов) не более громоздким кодом, а в последних примерах (разбиение по числу элементов и по суффиксу) даже более коротко. плюс ко всему код будет явно более понятным и читаемым, чем с использованием стримов. да, стримы дают больше функциональности и изящности коду, но они обязывают разработчиков знать весь используемый набор api, а значит уровень входа выше.. допускаю, в каких-то случаях использовать стримы даже удобно.. но тотальное использование в проекте это реально "стримоз".. не увидел в докладе самой главной проблемы стримов - обработка исключений.. как с этим бороться кроме как оборачивания checked в unchecked и последующего развертывания обратно?
Может кто-нибудь объяснить почему используются локальные переменные, например AtomicBoolean в примере 7, как глобальные в предикатах для метода filter??
Компилятор требует, чтобы захватываемая лямбдой (или анонимным классом) переменная была effectively final. Т.к. известно, что она не изменится, можно безнаказанно выводить её за пределы её скоупа. По сути будет использоваться копия значения. Тут описано подробнее itsobes.ru/JavaSobes/kak-v-liambde-izmenit-vneshniuiu-lokalnuiu-peremennuiu/
Тагир, спасибо тебе❤
В java 23
Stream gatherers, которые появились в Java 22 в режиме preview, остаются на второе preview без изменений.
Gatherers - это усовершенствование Stream API для поддержки произвольных промежуточных операций.
потрясающая презентация!!! то, что надо и просто образец как делать презентацию!! спасибо!
если серьезно оценивать, то все примеры в докладе сильно притянуты за уши.
все задачи можно решить обычным способом (без стримов) не более громоздким кодом, а в последних примерах (разбиение по числу элементов и по суффиксу) даже более коротко.
плюс ко всему код будет явно более понятным и читаемым, чем с использованием стримов.
да, стримы дают больше функциональности и изящности коду, но они обязывают разработчиков знать весь используемый набор api, а значит уровень входа выше..
допускаю, в каких-то случаях использовать стримы даже удобно.. но тотальное использование в проекте это реально "стримоз"..
не увидел в докладе самой главной проблемы стримов - обработка исключений.. как с этим бороться кроме как оборачивания checked в unchecked и последующего развертывания обратно?
Спасибо! Очень интересная тема и доклад
А можно ссылочку на презентацию?
Может кто-нибудь объяснить почему используются локальные переменные, например AtomicBoolean в примере 7, как глобальные в предикатах для метода filter??
Компилятор требует, чтобы захватываемая лямбдой (или анонимным классом) переменная была effectively final. Т.к. известно, что она не изменится, можно безнаказанно выводить её за пределы её скоупа. По сути будет использоваться копия значения. Тут описано подробнее itsobes.ru/JavaSobes/kak-v-liambde-izmenit-vneshniuiu-lokalnuiu-peremennuiu/
@@detarametawagotodsffasdg9067
10:40
привет. не подскажешь, что это за метод asList()?
я знаю только Arrays.asList(someArray). Но это же не он.
@@manOfPlanetEarth Хз, нужно ли через 5 месяцев, но это скорее всего просто статическим импорт Arrays.asList
@@TheSelecao9
да, это он самый)) я тогда не знал.
Нельзя радоваться Stream API после того, как познал LINQ. Который, минуточку, появился аж в 2008 году.
Единственное полезное выступление на этой конференции. Спасибо тебе, анонимный задрот.
Человек со стримозом мозга в квадрате, используя его же терминологию. 🤣
Рубашка в штанишки, штанишки в носочки, носочки в сандалики...
и зарплата в миллионах)