Всем привет!
Недавно вышла 22-я Java. Обычная, не LTS версия.
Вот неплохой обзор нововведений https://habr.com/ru/articles/801467/
Что могу отметить: из 12 JEP - больших фичей Java по сути - по которым велась работа в релизе, 7 появились в предыдущих версиях. Т.е фиксят и рефакторят.
Что же появилось интересного из новых фичей?
Launch Multi-File Source-Code Programs (JEP 458) - возможность быстрого запуска из командной строки без сборки в jar для кода, разбросанного по нескольким файлам. Запускать код из одного файла можно было и ранее.
Вместе с появившимся в 21 Java Implicitly Declared Classes and Instance Main Methods (Second Preview) (JEP 463) - запуск кода из простого метода main без параметров и без класса - видна тенденция упростить вкатывание новичков в Java, сделать его похожим на тот же Python.
Stream Gatherers (Preview) (JEP 461) - если раньше для стримов можно было писать свои коллекторы, то сейчас можно будет и gatherer - промежуточные операции. Кажется интересная тема, открывает возможности для большого расширения возможностей стримов. Странно, что ждали 14 версий)
Class-File API (Preview) (JEP 457) - если раньше для работы с байт-кодом использовались сторонние библиотеки, одна из которых - ASM - была первой среди равных, т.к. поставлялась с JDK, то сейчас сделали ее аналог уже в составе JDK. Цель - чтобы изменения в API Java и в API для работы с байт-кодом были синхронизированы. Тоже в общем-то вполне логичная фича.
Ну и еще одна мелкая фича, появление как я подозреваю которой приведет к тому, что появятся новые головоломные задачки на собесах. Statements before super(...) (Preview) (JEP 447) - как следует из названия в конструкторах можно писать код перед вызовом super(), но не любой, а только не нарушающий порядок инициализации класса. Это вам не Spring, никаких проксей) Т.е. код в прологе не должен ссылаться на конструируемый объект, включая поля из суперкласса и на экземпляры внутреннего класса.
P.S. Да, все еще идут споры по String Templates, про которые я писал ранее https://t.me/javaKotlinDevOps/246 Делать их расширяемыми или как у всех) В 22-й Java пока оставили как было
#java #java_new_version #interview_question
Недавно вышла 22-я Java. Обычная, не LTS версия.
Вот неплохой обзор нововведений https://habr.com/ru/articles/801467/
Что могу отметить: из 12 JEP - больших фичей Java по сути - по которым велась работа в релизе, 7 появились в предыдущих версиях. Т.е фиксят и рефакторят.
Что же появилось интересного из новых фичей?
Launch Multi-File Source-Code Programs (JEP 458) - возможность быстрого запуска из командной строки без сборки в jar для кода, разбросанного по нескольким файлам. Запускать код из одного файла можно было и ранее.
Вместе с появившимся в 21 Java Implicitly Declared Classes and Instance Main Methods (Second Preview) (JEP 463) - запуск кода из простого метода main без параметров и без класса - видна тенденция упростить вкатывание новичков в Java, сделать его похожим на тот же Python.
Stream Gatherers (Preview) (JEP 461) - если раньше для стримов можно было писать свои коллекторы, то сейчас можно будет и gatherer - промежуточные операции. Кажется интересная тема, открывает возможности для большого расширения возможностей стримов. Странно, что ждали 14 версий)
Class-File API (Preview) (JEP 457) - если раньше для работы с байт-кодом использовались сторонние библиотеки, одна из которых - ASM - была первой среди равных, т.к. поставлялась с JDK, то сейчас сделали ее аналог уже в составе JDK. Цель - чтобы изменения в API Java и в API для работы с байт-кодом были синхронизированы. Тоже в общем-то вполне логичная фича.
Ну и еще одна мелкая фича, появление как я подозреваю которой приведет к тому, что появятся новые головоломные задачки на собесах. Statements before super(...) (Preview) (JEP 447) - как следует из названия в конструкторах можно писать код перед вызовом super(), но не любой, а только не нарушающий порядок инициализации класса. Это вам не Spring, никаких проксей) Т.е. код в прологе не должен ссылаться на конструируемый объект, включая поля из суперкласса и на экземпляры внутреннего класса.
P.S. Да, все еще идут споры по String Templates, про которые я писал ранее https://t.me/javaKotlinDevOps/246 Делать их расширяемыми или как у всех) В 22-й Java пока оставили как было
#java #java_new_version #interview_question
Хабр
Вышла Java 22
Вышла общедоступная версия Java 22 . В этот релиз попало около 2300 закрытых задач и 12 JEP'ов . Release Notes можно посмотреть здесь . Полный список изменений API – здесь . Java 22 не является...
Всем привет!
Один из достаточно частых вопросов на собеседованиях - расскажите про стримы в Java, их плюсы и минусы. Если говорить о минусах - всегда под вопрос ставится быстродействие. У меня давно было желание его сравнить, но как часто бывает - меня опередили.
Вот неплохая статья про быстродействие стримов: https://habr.com/ru/articles/807647/
Какие выводы я сделал:
1) тот факт, что на небольшом объеме данных цикл forEach опережает любые виды стримов - ни о чем, им можно пренебречь. Как минимум в 99% случаев. Мне сложно представить кейс, когда объем данных невелик, но нужно выиграть миллисекунды. Скорее всего эти миллисекунды, или даже десятки миллисекунд, мы потеряем на сетевом взаимодействии. У нас же микросервисы, а это значит много сетевых вызовов. Если говорить о причинах - понятно, что на малых объемах данных накладные расходы, которые конечно же есть у стримов, играют роль. И еще момент - чем проще кусок кода, выполняющийся внутри стрима, тем больше отношение накладных расходов стримов к полезному действию.
2) parallelStream в большинстве случаев бьет forEach на больших объёмах данных. Почему так тоже понятно - эффект распараллеливание становится выше, чем накладные расходы на определенном объеме данных.
Итог: стримы можно использовать как вариант по умолчанию, т.к. они улучшают читаемость кода. В высоконагруженных приложениях\ больших объёмах данных имеет смысл смотреть в сторону parallelStream, особенно если есть результаты нагрузочного тестирования. Ну и только на каких-то критичных участках кода, имея на руках результаты НТ, имеет смысл переписать все на циклы
#streams #performance #interview_question
Один из достаточно частых вопросов на собеседованиях - расскажите про стримы в Java, их плюсы и минусы. Если говорить о минусах - всегда под вопрос ставится быстродействие. У меня давно было желание его сравнить, но как часто бывает - меня опередили.
Вот неплохая статья про быстродействие стримов: https://habr.com/ru/articles/807647/
Какие выводы я сделал:
1) тот факт, что на небольшом объеме данных цикл forEach опережает любые виды стримов - ни о чем, им можно пренебречь. Как минимум в 99% случаев. Мне сложно представить кейс, когда объем данных невелик, но нужно выиграть миллисекунды. Скорее всего эти миллисекунды, или даже десятки миллисекунд, мы потеряем на сетевом взаимодействии. У нас же микросервисы, а это значит много сетевых вызовов. Если говорить о причинах - понятно, что на малых объемах данных накладные расходы, которые конечно же есть у стримов, играют роль. И еще момент - чем проще кусок кода, выполняющийся внутри стрима, тем больше отношение накладных расходов стримов к полезному действию.
2) parallelStream в большинстве случаев бьет forEach на больших объёмах данных. Почему так тоже понятно - эффект распараллеливание становится выше, чем накладные расходы на определенном объеме данных.
Итог: стримы можно использовать как вариант по умолчанию, т.к. они улучшают читаемость кода. В высоконагруженных приложениях\ больших объёмах данных имеет смысл смотреть в сторону parallelStream, особенно если есть результаты нагрузочного тестирования. Ну и только на каких-то критичных участках кода, имея на руках результаты НТ, имеет смысл переписать все на циклы
#streams #performance #interview_question
Хабр
Еще раз о перформансе стримов в Java
Время от времени я наблюдаю или даже бываю втянутым в спор о перформансе стримов в джаве. Общеизвестно, что стримы это компромисс между перформансом и удобством. Однако я не нашел вменяемого набора...