Русский
Русский
English
Статистика
Реклама

Jmh

JPoint 2020 новый формат, новые возможности

04.07.2020 20:20:46 | Автор: admin
С 29 июня по 3 июля 2020 года в онлайн-формате прошла Java-конференция JPoint 2020. Информация о докладах, спикерах, особенностях проведения, впечатления от конференции всё это можно прочитать далее.



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

В предверии летнего блока конференций участники команды JUG Ru Group проделали титанический объём работы как административного, так и технического характера. Была создана онлайн-платформа для трансляции митапов и конференций. Также было проведено множество онлайн-встреч, в том числе Java-серия Первая чашка кофе с JPoint с интервью с участниками программного комитета и спикерами: Владимиром Ситниковым, Маргаритой Недзельской, Тагиром Валеевым, Олегом Докукой, Иваном Углянским и Алексеем Шипилёвым.

В блоге компании JUG Ru Group до летних конференций появилось множество интересных статей и интервью:

В проведении самой конференции произошли изменения:
  • стенды компаний превратились в виртуальную выставку с информацией о компании и возможностью назначения онлайн-встреч;
  • дискуссионные зоны для задания вопросов и общения после докладов тоже стали онлайновыми;
  • изменилось положение ведущих треков они стали играть значительно большую роль, помогая спикерам усилить впечатление от их докладов.

Открытие


Непосредственно перед открытием Алексей Фёдоров предоставил возможность увидеть пультовую Всевластья, помогающую организовать онлайн-конференции. После вводных слов и приветствия спонсоров конфереция была объявлена открытой.



Первый день


Прекрасным предисловием к интервью с James Gosling, отцом языка Java, стала статья, написанная phillennium. Беседу вели и задавали вопросы Андрей Дмитриев и Volker Simonis. Интервью получилось живое и эмоциональное, вызвавшее большой интерес у самого Джеймса. Было задано множество вопросов, от касающихся подробностей его прошлых проектов до отношения к популярному в настоящее время JVM-языку Kotlin. Безусловно, Джеймс является личностью, колоссальным образом повлиявшей на индустрию и внёсшей огромный вклад. Его присутствие в числе спикеров большая удача для конференции.



В перерыве между большими докладами можно было посмотреть познавательные интервью, одним из которых стало ML и AI: Как сейчас выглядит разработка решений в крупных компаниях Андрея Дмитриева с Дмитрием Бугайченко про машинное обучение и искусственный интеллект. Достаточно интересно было послушать мнение Дмитрия, являющегося экспертом в этой области и докладчиком этой и других конференций JUG Ru Group.



Доклад Precomputed data access with Micronaut Data от Graeme Rocher, автора Micronaut Framework. У данного спикера на конференции два доклада (доклад Micronaut deep dive был в этот же день чуть раньше, его я ещё планирую посмотреть). Очень полезным оказалось предварительное ознакомление с интервью, взятым недавно. В данном докладе было рассказано про Micronaut Data, легковесное решение для доступа к базам данных, выглядящее чрезвычайно привлекательно. После доклада Грэму вопросы слушателей и свои задавал Антон Архипов. На интересующий многих заданный Антоном вопрос, возможно ли использование Micronaut Data без всего остального из Micronaut Framework, был дан положительный ответ.



Второй день


В нативный код из уютного мира Java: Путешествие туда и обратно блестящий доклад Ивана Углянского на тему возможностей вызова из Java-кода процедур и функций нативных (native) библиотек. Всеобъемлющая ретроспектива существовавших до JNI альтернатив (JDK 1.0 NMI, RNI, JRI), популярных существующих сейчас (JNA, JNR, JavaCPP) и перспективных пока что экспериментальных (Panama, Sulong). Подробное сравнение всего современного вышеперечисленного (начиная с JNI) с большим количеством слайдов говорит об огромной проделанной работе. Очень удачные выбранные аналогии на тему произведений Толкиена: левый слайд (Шир) иллюстрирует милый и безопасный Java-код, правый слайд опасный нативный код (Мордор).



How to develop a successful Kubernetes native application using Quarkus небольшой пятнадцатиминутный доклад Alex Soto Bueno от компании RedHat, спонсора конференции. Доклад о разработке микросервисов с использованием Kubernetes и фреймворка Quarkus, детища RedHat.



Олег Шелаев является одним из тех спикеров, доклады которых всегда можно смело выбирать, зная, что совершенно точно будет интересно, увлекательно и полезно. Обладает редкой способностью просто объяснять очень сложные с технической точки зрения вещи. Доклад под названием Polyglot done right with GraalVM не стал исключением в этом смысле. В нём Олег продолжил раскрывать тему GraalVM, являясь developer advocate проекта GraalVM в OracleLabs. В данном докладе более полно была раскрыта направленность продукта на возможность одновременного применения различных языков программирования: API, шаблоны взаимодействия и прочие детали GraalVM. Ожидания от прослушанного полностью оправдались, отличный доклад.



Третий день


Всеволод Брекелов входит в команду JUG Ru Group, активно участвуя в проведении летнего блока конференций, к которому относится и конференция JPoint. Тем интереснее, регулярно видя его в роли ведущего конференций, было посмотреть доклад в его исполнении под названием Contract testing: Should or shouldn't? Ему очень удачно помогали Андрей Дмитриев, Владимир Плизга и Алексей Виноградов например, представление Владимиром докладчика в самом начале просто восхищает оригинальностью. Обсуждение было посвящено контрактным тестам, были последовательно продемонстрированы несколько подходов с использованием Spring Cloud Contract, Pact и Protocol Buffers. Получилось зажигательно и интересно.



Доклад Страх и ненависть в Scala и Kotlin interop от Маргариты Недзельской был посвящён проблемам взаимодействия кода, написанного на двух JVM-языках Kotlin и Scala. Название доклада является аллюзией на фильм Fear and Loathing in Las Vegas, им же достаточно оригинально был проиллюстрирован весь рассказ. Проблемы вызвали искреннее сочувствие, технические подробности были приведены весьма убедительные. Маргарите помогали Паша Финкельштейн и Евгений Мандриков, ведя беседу, озвучивая результаты голосований и задавая вопросы слушателей.



Четвёртый день


Ещё немного маленьких оптимизаций стал своеобразным продолжением доклада, сделанным на конференции Joker 2019 тем же автором, Тагиром Валеевым. Доклад первой части был посвящён улучшениям в строках, коллекциях и операциям с числами, в этот раз уже другим оптимизациям тоже в строках, коллекциях и теперь ещё и в reflection. Изменения, о которых было рассказано, произошли в версиях Java с 9 по 16. Традиционное глубокое понимание темы, множество результатов сравнений, характерные для докладов Тагира всё это было и в этот раз.



На Интервью и Q&A с Алексеем Шипилёвым интервьюеры Алексей Фёдоров и Иван Крылов поговорили и задали вопросы Алексею Шипилёву об особенностях работы в Red Hat, про используемые инструменты performance-инженера, про различия сборщиков мусора в Java, историю создания Shenandoah GC, об отношении к статьям с замерами производительности, мнении о GraalVM, про совместное использование jmh и async-profiler, о советах для молодых разработчиков и инженеров.



Пятый день


Совместный доклад настоящих звёзд конференций Баруха Садогурского и Евгения Борисова, озаглавленный ими Вырасти своего работодателя в условиях коронавируса, Или как сделать так, чтобы вас не уволили в кризис об особенностях удалённой работы, типах руководителей, проблемах при человеческих коммуникациях с рекомендациями для решения всех возникающих при этом проблем. Хороший нетехнический доклад в завершающий день конференции, демонстрация помех для работы при участии семьи Евгения Борисова в конце доклада была просто великолепна.



Внедрение open source-решений на примере Одноклассников: интервью Дмитрия Чуйко с Андреем Паньгиным. Одной из тем разговора стал переход компанией Одноклассники на использование дистрибутива Liberica JDK компании BellSoft, поэтому представляющий BellSoft Дмитрий Чуйко в качестве берущего интервью был весьма уместен. Также были упомянуты популярные проекты Андрея one-nio и async-profile, тоже являющиеся open source-решениями и вызывающие интерес и уважение.



Доклад Valhalla is coming от Сергея Куксенко был продолжение его же предыдущего доклада, сделанного им на Joker 2019. С конца октября 2019 года в разработке инлайн-типов произошли значительные изменения, подробно о которых было рассказано примерно с середины данного доклада. Сергей харизматичный спикер и высококвалифицированный инженер, доклады которого безошибочно всегда можно выбирать. Отлично дополнил доклад Иван Углянский, задававший вопросы и помогавший Сергею во взаимодействии со слушателями.



Прочие события


Кроме впечатляющей онлайн-платформы для стриминга конференций, всевозможных активностей во время их проведения к летним конференциям была выпущена новая версия веб-приложения, о котором ранее уже писалось в обзорах про конференции TechTrain 2019 и Joker 2019. Приложение доступно по ссылке, в репозитории на GitHub (ставьте звёздочки) имеется описание с информацией, включающей актуальную ссылку на веб-сайт.

Приложение, ранее бывшее только игрой по угадыванию спикера, теперь разделено на две части. В первой из них можно произвести поиск и просмотр информации обо всех конференциях JUG Ru Group, а также митапах Java-сообществ JUG.ru, JUG.MSK, JUGNsk. Содержится абсолютно та же информация, что и представленная на сайтах конференций и митапов. Доступны для удобного просмотра уже опубликованные видео и презентации докладов (ниже для примера показано отображение сведений об Антоне Архипове и об одном из его докладов).



В разделе со статистикой приведены сведения, которые могут заинтересовать как организаторов конференций, так и их участников: с какого времени проводится каждая из конференций или каждый из митапов, общая их длительность, количество конференций, докладов и спикеров, сколько из спикеров удостоено звания Java Champion или Most Valuable Professional (MVP). Можно щёлкнуть по картинкам для их увеличения (или посмотреть то же самостоятельно в веб-приложении по ссылке, приведённой выше).

Второй и третий скриншоты ниже показывают топ спикеров по количеству сделанных ими докладов (скриншот слева без учёта митапов, справа конференции вместе с митапами). Уверенную победу в обоих случаях (только конференции и конференции с митапами) одерживает Барух Садогурский, на втором месте Евгений Борисов. Третье месте в случае только конференций Кирилл Толкачёв, конференции с митапами Алексей Шипилёв.



В игре Угадай спикера, второй части веб-приложения, после загрузки данных обо всех конференциях и митапах стало возможным использовать все ранее доступные режимы угадывания для конкретной конференции (например, JPoint 2020). По умолчанию для угадывания предлагается в данный момент идущая либо ближайшая конференция. Дополнительно были реализованы возможности попытаться угадать Twitter, GitHub спикеров и, наоборот, спикера по представленному их Twitter, GitHub.



Закрытие


Процедура закрытия, сопровождавшаяся ранее полным зрителей залом и традиционным выходом на сцену спикеров, участников программного комитета и организаторов, в связи с онлайн-форматом претерпела существенные изменения. Кроме закрывающих конференцию Всеволода Брекелова и Алексея Фёдорова на экране можно было увидеть в прямом эфире многих организаторов и спикеров.



Совершенно точно, что в сложившейся сегодня ситуации команда JUG Ru Group сделала абсолютно всё возможное (мне кажется, что даже чуточку больше), чтобы праздник, которым конференция всегда бывает и для спикеров, и для обычных участников, состоялся. В какой-то степени, праздник можно продлить у каждого осталось много замечательных докладов, оставшихся пока непросмотренными, и имеется возможность поделиться своими впечатлениями от конференции в комментариях к статье.

Сезон летних конференций JUG Ru Group продолжается по-прежнему можно успеть присоединиться к оставшимся двум онлайн-конференциям DevOops (6-10 июля 2020 года) и Hydra (6-9 июля 2020 года). Есть возможность купить единый билет на все восемь конференций, видео докладов в этом случае становятся доступны сразу же после завершения конференций.
Подробнее..

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

24.04.2021 18:16:03 | Автор: admin

Какие есть причины переходить на новые версии Java? Кто-то это сделает из-за новых языковых возможностей вроде выражений switch, блоков текста или записей. Кому-то понадобятся новые интересные возможности вроде модулей или низкопаузных сборщиков мусора. Кто-то это сделает просто из-за того, что обновив версию Java, их программа станет быстрее и будет есть меньше памяти. Но есть ещё одна, не менее важная причина. Это новые API, которые позволят писать меньше кода и избежать траты времени на поиск нужной функциональности во внешних библиотеках. А в некоторых случаях сделают ваш код быстрее.


В предыдущих двух частях мы уже рассмотрели по 10 новых API, которые появились в Java 9 и более поздних версиях (часть 1, часть 2). Сегодня мы рассмотрим ещё 10.




1. Stream.toList()


Появился в: Java 16


Для какой задачи чаще всего используется Stream в Java? Конечно же, для трансформации списков: у нас есть список, над которым нужно совершить какое-то преобразование и вернуть новый. Такой паттерн вы наверняка видели в своём проекте множество раз:


List<T> targetList = sourceList        .stream()        // промежуточные операции        .collect(Collectors.toList());

Нельзя сказать, что collect(Collectors.toList()) является очень уж громоздкой конструкцией, но всё же хочется для такой частой операции писать поменьше кода. И в Java 16 это стало возможно с помощью нового метода Stream.toList():


List<T> targetList = sourceList        .stream()        // промежуточные операции        .toList();

Есть ли какая-то разница между toList() и collect(Collectors.toList())? Оба ли способа ведут себя одинаково? С практической точки зрения можно сказать, что нет: если toList() возвращает неизменяемый список, то collect(Collectors.toList()) возвращает некий список, о котором неизвестно, неизменяемый он или нет. То есть если вы нигде в коде не используете негарантированную вам спецификацией изменяемость списка (надеюсь, вы из такой категории людей), то смело можете заменять collect(Collectors.toList()) на toList().


Однако Stream.toList() делает код не только короче, но и эффективнее! Дело в том, что Stream.toList() использует внутри себя Stream.toArray(), который выделяет массив точной длины, если Spliterator имеет характеристику SIZED. В то время как Collectors.toList() никак эту характеристику не использует и всегда начинает с пустого ArrayList, накапливая в нём элементы с постоянными переаллокациями.


Давайте напишем несколько бенчмарков. Для начала рассмотрим самый простейший случай: замерим, как быстро создаётся копия исходного списка, т.е. проверим цепочку вообще без промежуточных операций. Так как для такого сценария Stream по идее вообще не нужен, и того же самого можно добиться просто вызвав new ArrayList<>(sourceList) или List.copyOf(sourceList), то замерим и эти два случая тоже:


Полный код JMH-бенчмарка
import org.openjdk.jmh.annotations.*;import java.util.ArrayList;import java.util.List;import java.util.concurrent.TimeUnit;import java.util.stream.Collectors;import java.util.stream.IntStream;@BenchmarkMode(Mode.AverageTime)@OutputTimeUnit(TimeUnit.NANOSECONDS)@State(Scope.Thread)public class ToList {    @Param({"10", "100", "1000"})    private int size;    private List<Integer> sourceList;    @Setup    public void setup() {        sourceList = IntStream                .range(0, size)                .boxed()                .collect(Collectors.toList());    }    @Benchmark    public List<Integer> newArrayList() {        return new ArrayList<>(sourceList);    }    @Benchmark    public List<Integer> toList() {        return sourceList.stream().toList();    }    @Benchmark    public List<Integer> copyOf() {        return List.copyOf(sourceList);    }    @Benchmark    public List<Integer> collectToList() {        return sourceList.stream().collect(Collectors.toList());    }    @Benchmark    public List<Integer> collectToUnmodifiableList() {        return sourceList.stream().collect(Collectors.toUnmodifiableList());    }}

Детали запуска бенчмарка
OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)Intel Core i5-9500 3.00GHZОпции запуска: -f 3 -wi 3 -w 5 -i 5 -r 5 -t 6 -jvmArgs -XX:+UseParallelGC


Результаты говорят нам о том, что Stream.toList() не только существенно быстрее collect(Collectors.toList()), но и может быть быстрее даже List.copyOf()! Это объясняется тем, что в List.copyOf() существенное время тратится на проверку requireNonNull для каждого входного элемента, поскольку он запрещает null-элементы, в то время как Stream.toList() не запрещает null и в нём такая проверка не нужна. На малых размерах List.copyOf() всё же выигрывает, потому что проверка нескольких элементов на null быстрее церемоний, которые есть у Stream: создание Spliterator, ReferencePipeline и т.д.


Теперь рассмотрим случай, когда точный размер неизвестен. Например, добавим одну промежуточную операцию filter():


Полный код JMH-бенчмарка
import org.openjdk.jmh.annotations.*;import java.util.ArrayList;import java.util.List;import java.util.concurrent.TimeUnit;import java.util.stream.Collectors;import java.util.stream.IntStream;@BenchmarkMode(Mode.AverageTime)@OutputTimeUnit(TimeUnit.NANOSECONDS)@State(Scope.Thread)public class ToListFilter {    @Param({"10", "100", "1000"})    private int size;    private List<Integer> sourceList;    @Setup    public void setup() {        sourceList = IntStream                .range(0, size)                .boxed()                .collect(Collectors.toList());    }    @Benchmark    public List<Integer> toList() {        return sourceList.stream().filter(i -> i % 2 == 0).toList();    }    @Benchmark    public List<Integer> newArrayList() {        var list = new ArrayList<Integer>();        for (var i : sourceList) {            if (i % 2 == 0) {                list.add(i);            }        }        return list;    }    @Benchmark    public List<Integer> collectToList() {        return sourceList.stream().filter(i -> i % 2 == 0).collect(Collectors.toList());    }    @Benchmark    public List<Integer> collectToUnmodifiableList() {        return sourceList.stream().filter(i -> i % 2 == 0).collect(Collectors.toUnmodifiableList());    }}

Детали запуска бенчмарка
OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)Intel Core i5-9500 3.00GHZОпции запуска: -f 3 -wi 3 -w 5 -i 5 -r 5 -t 6 -jvmArgs -XX:+UseParallelGC



В этом случае мы тоже получили большое ускорение! И в этот раз Stream.toList() на большом количестве элементов выиграл даже у простого new ArrayList() с последующим заполнением в цикле. Как так получается? Дело в том, что при неизвестном размере Stream.toArray() использует структуру данных SpinedBuffer, которая более эффективна для накопления элементов, чем ArrayList. Она представляет собой массив массивов, где подмассивы имеют длины в виде возрастающих степеней двойки (каждый следующий chunk в два раза больше предыдущего). Структуру SpinedBuffer можно легко понять из этого рисунка, где изображён буфер со 100 элементами (Integer от 0 до 99):



Также ArrayList проигрывает ещё и потому, что расширяется всего лишь в 1.5 раза при заполнении внутреннего массива, а значит делает это намного чаще, что приводит к дополнительным накладным расходам. ArrayList вынужден балансировать между экономией памяти и скоростью операции add(), поэтому и проигрывает SpinedBuffer, который заточен исключительно на скорость. Излишний расход памяти для него не играет роли, так как это недолгоживующая структура, которая сразу же отбрасывается после завершения терминальной операции.


Вывод: Stream.toList() короче, чище и почти всегда быстрее, чем collect(Collectors.toList()). Так что о втором способе можно забыть и использовать всегда первый (хотя Collectors.toList() сам по себе всё ещё может быть нужен, например как downstream Collector для других Collector'ов). Если же нужен гарантированно изменяемый список, то можно использовать collect(Collectors.toCollection(ArrayList::new)).



2. String: formatted(), stripIndent() и translateEscapes()


Появились в: Java 15


В Java 15 появились блоки текста строковые литералы, которые могут состоять из одной или нескольких линий:


String str = """        Привет,        Юзер!""";

При этом довольно часто блоки будут использоваться в качестве шаблонов с последующей заменой:


String str = String.format("""        Привет,        %s!""", user);

Не кажется ли вам, что код выше выглядит несколько громоздким? Мне вот тоже кажется. Но у нас есть способ, как сделать его немножко чище. Это новый метод String.formatted(), который является нестатическим эквивалентом String.format():


String str = """        Привет,        %s!""".formatted(user);

Вы, конечно, скажете, что разница лишь в трёх символах сэкономленного кода, но, во-первых, второй вариант гораздо проще печатать на клавиатуре (проверьте сами), а во-вторых, он более читабелен.


Кстати, formatted() никто не запрещает использовать и с обычными литералами:


String str = "Привет, %s!".formatted(user);

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



Второй метод, появившийся в Java 15 это String.stripIndent(), который удаляет общие пробельные символы в начале всех линий. К примеру, если есть файл hello.txt с такими строками:


    Привет,    Юзер!

Тогда чтобы убрать пробелы слева, как раз и можно воспользоваться stripIndent():


String str = Files.readString(Path.of("hello.txt")).stripIndent();System.out.println(str);

Вывод:


Привет,Юзер!


Наконец, третий метод это String.translateEscapes(). Он делает простую вещь: заменяет экранирующие последовательности на их соответствующие символы.


Например, есть файл hello.txt:


Привет,\nЮзер!

String str = Files.readString(Path.of("hello.txt")).translateEscapes();System.out.println(str);

Вывод:


Привет,Юзер!


3. CharSequence.isEmpty(), CharSequence.compare() и StringBuilder.compareTo()


Появились в: Java 15 / Java 11


Если уж мы начали тему строк, то давайте добьём её до конца.


Тот, кто писал на Java 1.5 или на более старых версиях, должен помнить, что в классе String в те времена не было метода isEmpty(). Поэтому для проверки строки на пустоту каждый раз приходилось использовать length():


if (str.length() != 0) {    ...}

Это было не совсем удобно, и в Java 1.6 метод String.isEmpty() наконец-то завезли:


if (!str.isEmpty()) {    ...}

Однако про то, что String далеко не единственная реализация CharSequence (хоть и самая популярная), почему-то не подумали, и этот метод туда добавлять не стали (впрочем, без default-методов они бы этого сделать и не смогли). Например, для проверки на пустоту StringBuilder всё ещё приходилось использовать length():


if (stringBuilder.length() != 0) {    ...}

Но спустя 14 лет всё-таки решили исправить и это: начиная с Java 15, метод isEmpty() есть не только у String, но и у любой CharSequence:


if (!stringBuilder.isEmpty()) {    ...}


Также иногда приходится тестировать два CharSequence на равенство. Метод equals() использовать нельзя: а вдруг он не переопределён в реализации? Поэтому приходится изворачиваться: либо конвертировать каждый CharSequence в String и сравнивать их, что может быть накладно, либо писать свою реализацию посимвольного сравнения.


Однако, начиная с Java 11, всё это не нужно, потому что появился метод CharSequence.compare():


if (CharSequence.compare(charSeq1, charSeq2) == 0) {    ...}

Метод compare() также можно использовать не только для просто теста на равенство, но и для лексикографического сравнения.


Также в Java 11 класс StringBuilder стал реализовывать интерфейс Comparable, а значит для сравнения двух StringBuilder можно использовать compareTo():


if (stringBuilder1.compareTo(stringBuilder2) == 0) {    ...}


4. Collectors.filtering() и Collectors.flatMapping()


Появились в: Java 9


Часто ли вам приходится использовать Collectors.groupingBy()? К примеру, вы ведёте базу данных фильмов:


record Movie(String title, String genre, double rating) {}

Допустим, вы хотите сгруппировать фильмы по жанру:


Stream<Movie> allMovies = Stream.of(    new Movie("Коммандо", "Боевик", 7.385),    new Movie("Терминатор", "Боевик", 7.974),    new Movie("Терминатор 2", "Боевик", 8.312),    new Movie("Молчание ягнят", "Триллер", 8.33),    new Movie("Криминальное чтиво", "Триллер", 8.619),    new Movie("Титаник", "Мелодрама", 8.363),    new Movie("Семьянин", "Комедия", 7.699));Map<String, List<Movie>> groups = allMovies.collect(    Collectors.groupingBy(Movie::genre));groups.forEach((genre, movies) -> {    System.out.println(genre + ":");    movies.forEach(movie ->        System.out.printf("    %s: %.2f%n", movie.title(), movie.rating()));});

Вывод:


Мелодрама:    Титаник: 8.36Боевик:    Коммандо: 7.39    Терминатор: 7.97    Терминатор 2: 8.31Триллер:    Молчание ягнят: 8.33    Криминальное чтиво: 8.62Комедия:    Семьянин: 7.70

Однако, допустим, вы не хотите видеть все фильмы, а только те, у кого рейтинг выше 8. Какой метод вы в этом случае используете? Конечно же, Stream.filter():


Map<String, List<Movie>> groups = allMovies    .filter(movie -> movie.rating() > 8)    .collect(Collectors.groupingBy(Movie::genre));

Мелодрама:    Титаник: 8.36Боевик:    Терминатор 2: 8.31Триллер:    Молчание ягнят: 8.33    Криминальное чтиво: 8.62

Но вот проблема: вам вдруг захотелось видеть все жанры, даже те, в которые не попало ни одного фильма с рейтингом выше 8. Что делать? Ответ: перейти на новую версию Java, потому что в ней есть Collectors.filtering():


Map<String, List<Movie>> groups = allMovies.collect(    Collectors.groupingBy(Movie::genre,        Collectors.filtering(movie -> movie.rating() > 8,            Collectors.toList())));groups.forEach((genre, movies) -> {    System.out.println(genre + ":");    if (movies.isEmpty()) {        System.out.println("    <Фильмов с рейтингом выше 8 нет>");    } else {        movies.forEach(movie ->            System.out.printf("    %s: %.2f%n", movie.title(), movie.rating()));    }});

В этом случае фильтрация будет перенесена внутрь groupingBy(), и потери жанров не произойдёт:


Мелодрама:    Титаник: 8.36Боевик:    Терминатор 2: 8.31Триллер:    Молчание ягнят: 8.33    Криминальное чтиво: 8.62Комедия:    <Фильмов с рейтингом выше 8 нет>


Очень хорошо. Теперь добавим в фильмы актёров:


record Movie(String title, String genre, double rating, List<String> actors) {}

И теперь хотите увидеть всех актёров с группировкой по жанру:


Stream<Movie> allMovies = Stream.of(    new Movie("Коммандо", "Боевик", 7.385,        List.of("Шварценеггер", "Чонг", "Хедайя")),    new Movie("Терминатор", "Боевик", 7.974,        List.of("Шварценеггер", "Бин", "Хэмилтон")),    new Movie("Терминатор 2", "Боевик", 8.312,        List.of("Шварценеггер", "Хэмилтон", "Ферлонг", "Патрик")),    new Movie("Молчание ягнят", "Триллер", 8.33,        List.of("Фостер", "Хопкинс")),    new Movie("Криминальное чтиво", "Триллер", 8.619,        List.of("Траволта", "Уиллис", "Джексон", "Турман")),    new Movie("Титаник", "Мелодрама", 8.363,        List.of("ДиКаприо", "Уинслет")),    new Movie("Семьянин", "Комедия", 7.699,        List.of("Кейдж", "Леони")));

Но какой коллектор нужно подсунуть в groupingBy(), чтобы собрать всех актёров в Set? Можно попробовать Collectors.mapping():


Map<String, Set<List<String>>> groups = allMovies.collect(    Collectors.groupingBy(Movie::genre,        Collectors.mapping(Movie::actors, Collectors.toSet())));

Но смотрите, у нас получилось множество списков, а нужно просто множество. Что же делать? И тут на помощь приходит Collectors.flatMapping(), ещё один новый метод, появившийся в Java 9:


Map<String, Set<String>> groups = allMovies.collect(    Collectors.groupingBy(Movie::genre,        Collectors.flatMapping(movie -> movie.actors().stream(),            Collectors.toSet())));

И вот сейчас тип правильный! Если вывести это, то получится:


Мелодрама:    ДиКаприо    УинслетБоевик:    Бин    Ферлонг    Хедайя    Патрик    Шварценеггер    Хэмилтон    ЧонгТриллер:    Траволта    Уиллис    Хопкинс    Фостер    Джексон    ТурманКомедия:    Кейдж    Леони

Что и требовалось.



5. StackWalker


Появился в: Java 9


Приходилось ли вам иметь дело со стеками? Не со стеками в смысле структур данных, а со стеком потоков? Например, вы пишете простенький логгер:


public final class MyLogger {    public static void log(String message) {        System.out.println(message);    }}

Однако вы хотите писать в консоль не просто голое сообщение, а ещё имя класса, метода, файла и номер строки, откуда вызывается метод log(). В Java 8 единственным стандартным способом для этого является получение массива StackTraceElement[], например, с помощью метода Thread.getStackTrace():


public static void log(String message) {    StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();    StackTraceElement stackTraceElement = stackTrace[2];    String msg = stackTraceElement.getClassName() + "."               + stackTraceElement.getMethodName() + "("               + stackTraceElement.getFileName() + ":"               + stackTraceElement.getLineNumber() + ") "               + message;    System.out.println(msg);}

Можно предположить, что такой способ получения получения номеров строк является довольно дорогим. Ведь нам надо заполнить полностью весь стек, который может быть очень глубоким (особенно в энтерпрайзе, где фреймворк на фреймворке), а потом ещё и сконвертировать внутренние структуры JVM в Java-массив. И всё это ради того, чтобы отбросить его почти полностью и достать только второй элемент. Давайте замерим производительность такого подхода:


@Benchmarkpublic String stackTrace() {    StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();    StackTraceElement stackTraceElement = stackTrace[2];    return stackTraceElement.getClassName() + "."         + stackTraceElement.getMethodName() + "("         + stackTraceElement.getFileName() + ":"         + stackTraceElement.getLineNumber() + ")";}

Детали запуска бенчмарка
OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)Intel Core i5-9500 3.00GHZОпции запуска: -f 1 -wi 3 -w 3 -i 5 -r 5 -t 6

Benchmark          Mode  Cnt    Score   Error  UnitsStack.stackTrace   avgt    5  103,704 ? 1,123  us/op

104 микросекунды на каждый вызов! Это невероятно медленно! Есть ли возможность это ускорить? Есть: с помощью нового класса StackWalker, который появился в Java 9. Давайте рассмотрим этот класс поподробнее.


StackWalker предоставляет возможность гулять по стеку. Чтобы это сделать, сначала нужно получить экземпляр StackWalker с помощью метода StackWalker.getInstance(). Этот метод возвращает StackWalker по умолчанию. Также есть возможность передать в метод getInstance() опции и получить StackWalker с более богатыми возможностями. Но об этом чуть позже.


После того, как мы получил объект StackWalker, у нас есть следующие варианты:


  • Выполнить на нём метод forEach() и пройтись по всем фреймам стека.
  • Вызвать метод getCallerClass() и получить класс, который вызвал наш метод (работает только с опцией RETAIN_CLASS_REFERENCE).
  • Вызвать метод walk(), который принимает функцию из Stream<StackFrame> в T, где T это что угодно. Это самый гибкий метод.

Для нашего логгера мы воспользуемся третьим вариантом. Вот как будет выглядеть реализация метода log():


public static void log(String message) {    String msg = StackWalker        .getInstance()        .walk((Stream<StackFrame> frames) -> {            StackFrame frame = frames.skip(2).findFirst().get();            return frame.getClassName() + "."                 + frame.getMethodName() + "("                 + frame.getFileName() + ":"                 + frame.getLineNumber() + ") "                 + message;        });    System.out.println(msg);}

Теперь давайте замерим производительность варианта со StackWalker:


@Benchmarkpublic String stackWalker() {    return StackWalker        .getInstance()        .walk(frames -> {            StackFrame frame = frames.skip(2).findFirst().get();            return frame.getClassName() + "."                 + frame.getMethodName() + "("                 + frame.getFileName() + ":"                 + frame.getLineNumber() + ")";        });}

Детали запуска бенчмарка
OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)Intel Core i5-9500 3.00GHZОпции запуска: -f 1 -wi 3 -w 3 -i 5 -r 5 -t 6

Benchmark          Mode  Cnt    Score   Error  UnitsStack.stackTrace   avgt    5  103,704 ? 1,123  us/opStack.stackWalker  avgt    5    2,781 ? 0,156  us/op

Скорость выросла в 37 раз! Это огромный выигрыш. Конечно, 2.8 микросекунды это всё ещё далеко не бесплатно, но такой вариант кажется уже вполне приемлемым, чтобы включить его в боевом приложении.


Так как метод StackWalker.walk() даёт нам Stream, то наши возможности по обходу стека практически безграничны: можно получить все фреймы, можно отфильтровать, можно пропустить сколько-то. Например, усложним наш логирующий фреймворк, добавив туда уровни:


package org.mylogger;public final class MyLogger {    public enum Level {        ERROR, WARN, INFO    }    public static void error(String message) {        log(Level.ERROR, message);    }    public static void warn(String message) {        log(Level.WARN, message);    }    public static void info(String message) {        log(Level.INFO, message);    }    public static void log(Level level, String message) {        ...    }}

Сейчас мы уже не можем использовать конструкцию frames.skip(2), потому что метод log() может быть вызван как напрямую, так и через методы error(), warn(), log(), а значит фрейм надо искать немножко умнее. Самое простое через Stream.dropWhile():


public static void log(Level level, String message) {    String msg = StackWalker        .getInstance()        .walk((Stream<StackFrame> frames) -> {            StackFrame frame = frames                .dropWhile(f -> f.getClassName().startsWith("org.mylogger"))                .findFirst()                .get();            return level + " "                 + frame.getClassName() + "."                 + frame.getMethodName() + "("                 + frame.getFileName() + ":"                 + frame.getLineNumber() + ") "                 + message;        });    System.out.println(msg);}


Какие ещё применения есть у StackWalker?


Как вы знаете, в Java 9 появились модули. Но мало кто использует их в своих проектах, и подавляющее большинство всё ещё препочитает класть всё в classpath. Но тогда у нас теряется весьма ценная возможность экспортировать из модуля часть пакетов, а остальные скрывать. Представим, что у нас есть пакет org.example.mylib.internal, который мы хотим, чтобы не использовал никто кроме нашего модуля:


package org.example.mylib.internal;public final class Handler {    public static void handle() {        ...    }}

Класс Handler публичный, а значит компилятор уже никак не помешает кому угодно использовать этот класс. Но, может быть, можно сделать хотя бы проверку в рантайме? И действительно, это можно сделать через StackWalker.getCallerClass(), и выглядеть этот будет примерно так:


package org.example.mylib.internal;public final class Handler {    public static void handle() {        if (!StackWalker            .getInstance(Option.RETAIN_CLASS_REFERENCE)            .getCallerClass()            .getPackageName()            .startsWith("org.example.mylib.")) {            throw new RuntimeException("Security error");        }        ...    }}

Здесь мы использовали опцию RETAIN_CLASS_REFERENCE, иначе получить Class не получилось бы. В принципе, подобную функциональность можно было бы реализовать и через Stream.walk(), но getCallerClass() работает немного быстрее.



6. System.Logger


Появился в: Java 9


Если уж мы начали говорить про логирование, то нельзя не рассказать про новое стандартное API для логирования, которое появилось в Java 9. Это API очень маленькое и состоит всего из трёх классов: интерфейса System.Logger, абстрактного класса System.LoggerFinder и перечисления System.Logger.Level.


Использовать System.Logger чрезвычайно просто:


public final class Main {    private static final Logger LOGGER = System.getLogger("");    public static void main(String[] args)  {        LOGGER.log(Level.ERROR, "Critical error!");    }}

Вывод:


апр. 17, 2021 6:24:57 PM org.example.Main mainSEVERE: Critical error!

System.Logger это не новый очередной фреймворк для логирования, как вы могли бы подумать сначала, а только фронтенд для логирования. Если вы знакомы с существующими фреймворками, то вам должно быть это знакомо: например, SLF4J это фронтенд, а его соответствующим бэкендом является Logback. Или Log4j API это фронтенд для Log4j Core. Так вот, System.Logger это фронтенд для знакомого вам фреймворка java.util.logging, который находится в отдельном модуле java.logging.


При этом нам ничего не мешает для SLF4J использовать другой бэкенд, например, Log4j или java.util.logging. Или для Log4j API использовать SLF4J как бэкенд или java.util.logging. Точно так же и с System.Logger: он спроектирован так, чтобы реализация могла быть абсолютно любой. Если не нравится неудобный и старый java.util.logging, то можно использовать что-то другое. Например, можно его настроить на современный Log4j, для чего потребуется подключить следующие зависимости:


<dependency>    <groupId>org.apache.logging.log4j</groupId>    <artifactId>log4j-api</artifactId>    <version>2.14.1</version> <!-- Последняя версия на момент написания статьи -->    <scope>runtime</scope></dependency><dependency>    <groupId>org.apache.logging.log4j</groupId>    <artifactId>log4j-core</artifactId>    <version>2.14.1</version>    <scope>runtime</scope></dependency><dependency>    <groupId>org.apache.logging.log4j</groupId>    <artifactId>log4j-jpl</artifactId>    <version>2.14.1</version>    <scope>runtime</scope></dependency>

При этом саму программу изменять не потребуется: то, что log4j-jpl окажется в classpath, уже будет достаточно. Java через ServiceLoader найдёт нужную реализацию LoggerFinder в виде Log4jSystemLoggerFinder и будет направлять логи в Log4j:


18:24:57.941 [main] ERROR  - Critical error!

После этого модуль java.logging можно будет даже вообще исключить из JRE/JDK, ведь он больше не нужен (если вы конечно нигде не вызываете java.util.logging напрямую).


К сожалению, адаптера System.Logger для SLF4J/Logback нет. Но тут проблема более глобальная похоже, что сам проект SLF4J мёртв. Последний коммит в GitHub был полтора года назад. Так что Log4j сейчас это самый нормальный вариант он активно развивается и поддерживается.


Несколько примеров использования System.Logger:


LOGGER.log(Level.INFO, "Information");LOGGER.log(Level.DEBUG, "Sum of {} and {} is {}:", 2, 3, 2+3);LOGGER.log(Level.TRACE, () -> "Lazy message");LOGGER.log(Level.ERROR, "Log exception", new Exception());


7. Lookup.defineHiddenClass()


Появился в: Java 15


В прошлый раз мы рассказывали про метод MethodHandles.Lookup.defineClass(), с помощью которого можно во время выполнения легко загрузить класс в том же пакете, не создавая при этом новый загрузчик класса. Это очень удобный метод, но у него есть существенный минус: класс, который загружен таким образом, будет до конца жизни висеть в памяти (по крайней мере до конца жизни текущего загрузчика класса). Это не очень подходит для приложений, которым требуется динамически генерировать и загружать много временных классов на лету. Но с Java 15 появилась альтернатива в виде нового вида классов, которые называются скрытыми.


Скрытые классы создаются с помощью нового метода Lookup.defineHiddenClass(). По сути этот метод очень похож на старый нестандартный метод Unsafe.defineAnonymousClass(), который много лет используется различными фреймворками, поскольку решает проблему неконтролируемого роста количества временных классов в памяти. При этом сам Unsafe.defineAnonymousClass() с Java 15 стал deprecated for removal.


Скрытые классы имеют следующие особенности:


  • На них не могут прямо ссылаться другие классы. Всё их использование может осуществляться исключительно через рефлексию.
  • Они являются необнаружимыми. Их нельзя найти ни по имени, ни обнаружить с помощью загрузчиков классов (через Class.forName(), ClassLoader.loadClass(), ClassLoader.findLoadedClass() и т.д.). Однако скрытые классы не являются анонимными и всё-таки имеют имя в формате <имя класса в байт-коде>/<suffix> (например, org.example.Temp/0x0000000800cb8000).
  • Они реализованы таким способом, что не связаны сильной ссылкой с загрузчиком класса, а значит могут быть собраны сборщиком мусора, когда их Class становится недостижимым (но если хочется, то это можно переопределить, передав опцию ClassOption.STRONG в defineHiddenClass()).
  • Они не появляются в стектрейсах, если только не включить опции -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames.

Кстати, вы уже должны быть хорошо знакомы со скрытыми классами, поскольку используете их каждый день. Это лямбды:


jshell> Runnable runnable = () -> {}runnable ==> $Lambda$26/0x0000000800c0aa00@443b7951jshell> runnable.getClass().isHidden()$2 ==> true


Давайте создадим небольшой примерчик и определим свой скрытый класс с нуля. Пусть он для простоты складывает два int'а. Для разнообразия будем это делать не с помощью javac, а через ByteBuddy.


Для начала нужно создать представление класса в байт-коде в виде массива байтов:


byte[] bytes = new ByteBuddy()        .subclass(Object.class)        .name("org.example.Temp")        .defineMethod("sum", int.class, Modifier.PUBLIC)        .withParameters(int.class, int.class)        .intercept(new Implementation.Simple(                MethodVariableAccess.INTEGER.loadFrom(1),                MethodVariableAccess.INTEGER.loadFrom(2),                Addition.INTEGER,                MethodReturn.INTEGER))        .make()        .getBytes();

По сути мы скомпилировали вот такой класс, но сделали это в рантайме непосредственно через манипуляции с байт-кодом:


package org.example;public class Temp {    public int sum(int x, int y) {        return x + y;    }}

Теперь, когда у нас есть байт-код класса, можно его загружать и что-то с ним делать:


Lookup lookup = MethodHandles        .lookup()        .defineHiddenClass(bytes, false);// Для разнообразия будем использовать MethodHandle вместо reflectionObject obj = lookup        .findConstructor(lookup.lookupClass(), MethodType.methodType(void.class))        .invoke();MethodHandle sumHandle = lookup.findVirtual(lookup.lookupClass(), "sum",        MethodType.methodType(int.class, int.class, int.class));// Вызовем метод sum. Должен напечатать 5System.out.println(sumHandle.invoke(obj, 3, 2));

Вот и всё.



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


Lookup lookup1 = MethodHandles.lookup().defineHiddenClass(bytes, false);Lookup lookup2 = MethodHandles.lookup().defineHiddenClass(bytes, false);Lookup lookup3 = MethodHandles.lookup().defineHiddenClass(bytes, false);System.out.println(lookup1.lookupClass()); // class org.example.Temp/0x0000000800cb4000System.out.println(lookup2.lookupClass()); // class org.example.Temp/0x0000000800cb4400System.out.println(lookup3.lookupClass()); // class org.example.Temp/0x0000000800cb4800


8. Новые методы в Math


Появились в: Java 9 / Java 15


Наверное, практически все, кто начинал работать с большими числами в Java, совершал вот такую ошибку:


int x = ...int y = ...long z = x * y;

Это один из тех примеров в Java, когда можно угодить в ловушку даже на простом умножении: произведение двух int это тоже int, а значит то, что переменная z имеет тип long, от переполнения никак не спасает. Для исправления этой ошибки нужно явно прикастовать хотя бы один из множителей к long:


long z = (long) x * y;

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


Возьми два int и перемножь их в long с учётом переполнения

И с Java 9 такой способ есть. Это метод Math.multiplyFull():


long z = Math.multiplyFull(x, y);


Вообще обработка переполнений в Java реализуется довольно муторно, и чтобы облегчить жизнь программистам, в Java 8 появилась целая пачка методов для этого в классе Math:


  • int toIntExact(long value)
  • int incrementExact(int a)
  • long incrementExact(long a)
  • int decrementExact(int a)
  • long decrementExact(long a)
  • int negateExact(int a)
  • long negateExact(long a)
  • int addExact(int x, int y)
  • long addExact(long x, long y)
  • int subtractExact(int x, int y)
  • long subtractExact(long x, long y)
  • int multiplyExact(int x, int y)
  • long multiplyExact(long x, long y)

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


jshell> Math.abs(Integer.MIN_VALUE)$1 ==> -2147483648

Как же так, ведь модуль это положительное число? Это так, но дело в том, что 2147483648 просто не влезает в int, поэтому этот отдельный случай является исключением. Чтобы вот так по чистой случайности не напороться на такое, можно обезопасить себя методом Math.absExact(), который появился в Java 15:


jshell> Math.absExact(Integer.MIN_VALUE)|  Exception java.lang.ArithmeticException: Overflow to represent absolute value of Integer.MIN_VALUE|        at Math.absExact (Math.java:1392)|        at (#1:1)jshell> Math.absExact(Long.MIN_VALUE)|  Exception java.lang.ArithmeticException: Overflow to represent absolute value of Long.MIN_VALUE|        at Math.absExact (Math.java:1438)|        at (#2:1)


А знаете ли вы, сколько будет, если найти целое от деления -11 на 3? А остаток? Давайте проверим:


jshell> -11 / 3$1 ==> -3jshell> -11 % 3$2 ==> -2

Ну вроде бы логично, ведь -11 = 3 * (-3) - 2. Однако если вы выполните то же самое, например, на Python, то получите совсем иной результат:


>>> -11 / 3-4>>> -11 % 31

И этот результат тоже по-своему верный: -11 = 3 * (-4) + 1. Дело в том, что есть два способа деления целых чисел: с обрезанием в сторону нуля и с обрезанием в сторону минус бесконечности. Java выбрала первый способ, Python второй. Ну а что делать, если я хочу в Java делить по-питоновски? Для этого в Java 9 появились методы Math.floorDiv() и Math.floorMod():


jshell> Math.floorDiv(-11, 3)$1 ==> -4jshell> Math.floorMod(-11, 3)$2 ==> 1


Также для совсем упоротых математиков в Java 9 появились два метода Math.fma(float, float, float) и Math.fma(double, double, double), которые делают то же самое, что и a * b + c, но только точнее, потому что используют специальную отдельную инструкцию процессора:


jshell> Math.fma(2.99, 5.91, 7.1)$1 ==> 24.7709jshell> 2.99 * 5.91 + 7.1$2 ==> 24.770900000000005


9. Аннотация java.io.Serial


Появилась в: Java 14


Используете ли вы стандартную сериализацию в Java? Этот механизм далеко не идеальный и со своими недостатками, но иногда он может быть очень удобным, потому что позволяет из коробки очень просто сделать сереализацию и десериализацию Java-объектов. Рассмотрим пример:


public class Point {    private static final long serialVersionUID = 1L;    public int x;    public int y;}

Чтобы сконвертировать объект Point в массив байтов, нужно написать всего несколько строчек:


var point = new Point();point.x = 1;point.y = 2;var baos = new ByteArrayOutputStream();try (var oos = new ObjectOutputStream(baos)) {    oos.writeObject(point);}byte[] bytes = baos.toByteArray();


Очень удобно. Кстати, вы заметили ошибку в моём коде? Конечно же, я забыл реализовать интерфейс Serializable! (Я специально добавил поле serialVersionUID, чтобы отвлечь ваше внимание.)


Правильный код будет таким:


public class Point implements Serializable {    private static final long serialVersionUID = 1;    public int x;    public int y;}

И вот это как раз и есть одна из главных проблем сериализации при её использовании можно очень легко допустить ошибку: забыть Serializable, опечататься в названии поля serialVersionUID, забыть сделать его статическим и т.д. Чтобы немного обезопаситься от такого, в Java 14 ввели новую аннотацию Serial.


Этой аннотацией теперь рекомендуется помечать все поля и методы, относящиеся к механизму сериализации:


public class Point implements Serializable {    @Serial    private static final long serialVersionUID = 1;    ...}

Теперь, если будет допущена ошибка, то появится предупреждение:


public class Point {    @Serial // Annotated member is not a part of the serialization mechanism    private static final long serialVersionUID = 1;    ...}

Или:


public class Point implements Serializable {    @Serial // Annotated member is not a part of the serialization mechanism    private static final int serialVersionUID = 1;    ...}

Аннотация будет делать проверки на всех полях и методах, которые относятся к сериализации: serialVersionUID, serialPersistentFields, writeObject(), readObject() и т.д.


К сожалению, на текущий момент предупреждения хорошо работают только в IntelliJ IDEA. В компиляторе JDK 16 проверки выполняются только с включённым флагом -Xlint:serial и работают не все. Например, для двух примеров выше javac ругается только во втором случае:


> javac -Xlint:serial Point.javaPoint.java:6: warning: [serial] serialVersionUID must be of type long in class Point    private static final int serialVersionUID = 1;                             ^

Возможно, это исправят в Java 17.



10. Методы Objects: checkIndex(), checkFromIndexSize(), checkFromToIndex()


Появились в: Java 9 / Java 16


Завершим нашу статью несколькими полезными методами для проверки индексов.


Иногда приходится писать функции, принимающие в качестве входных параметров индексы или диапазоны индексов, и чтобы начать использовать эти индексы, нужно сначала убедиться, что они не выходят за границы. То есть приходится писать подобные проверки в начале методов:


private static void getAt(int index, int length) {    if (index < 0) {        throw new IllegalArgumentException("index < 0");    }    if (index >= length) {        throw new IllegalArgumentException("index >= length");    }    ...}

Если подобных функций в проекте становится уже несколько, то чтобы не повторяться, такие проверки удобнее вынести в отдельные утилитные методы:


public final class PreconditionUtils {    public static void checkIndex(int index, int length) {        if (index < 0) {            throw new IllegalArgumentException("index < 0");        }        if (index >= length) {            throw new IllegalArgumentException("index >= length");        }    }}


Но с Java 9 теперь это больше не нужно, потому что в классе Objects теперь есть стандартные методы проверок индексов.


Метод Objects.checkIndex() проверяет, что индекс находится в диапазоне [0, length):


jshell> Objects.checkIndex(-3, 10)|  Exception java.lang.IndexOutOfBoundsException: Index -3 out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckIndex (Preconditions.java:70)|        at Preconditions.checkIndex (Preconditions.java:248)|        at Objects.checkIndex (Objects.java:372)|        at (#1:1)jshell> Objects.checkIndex(10, 10)|  Exception java.lang.IndexOutOfBoundsException: Index 10 out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckIndex (Preconditions.java:70)|        at Preconditions.checkIndex (Preconditions.java:248)|        at Objects.checkIndex (Objects.java:372)|        at (#2:1)


Метод Objects.checkFromIndexSize() проверяет, что диапазон [fromIndex, fromIndex + size) находится в диапазоне [0, length):


jshell> Objects.checkFromIndexSize(3, 8, 10)|  Exception java.lang.IndexOutOfBoundsException: Range [3, 3 + 8) out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckFromIndexSize (Preconditions.java:82)|        at Preconditions.checkFromIndexSize (Preconditions.java:343)|        at Objects.checkFromIndexSize (Objects.java:424)|        at (#3:1)jshell> Objects.checkFromIndexSize(-2, 8, 10)|  Exception java.lang.IndexOutOfBoundsException: Range [-2, -2 + 8) out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckFromIndexSize (Preconditions.java:82)|        at Preconditions.checkFromIndexSize (Preconditions.java:343)|        at Objects.checkFromIndexSize (Objects.java:424)|        at (#4:1)jshell> Objects.checkFromIndexSize(3, -4, 10)|  Exception java.lang.IndexOutOfBoundsException: Range [3, 3 + -4) out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckFromIndexSize (Preconditions.java:82)|        at Preconditions.checkFromIndexSize (Preconditions.java:343)|        at Objects.checkFromIndexSize (Objects.java:424)|        at (#5:1)


Наконец, метод Objects.checkFromToIndex() проверяет, что диапазон [fromIndex, toIndex) находится в диапазоне [0, length):


jshell> Objects.checkFromToIndex(3, 11, 10)|  Exception java.lang.IndexOutOfBoundsException: Range [3, 11) out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckFromToIndex (Preconditions.java:76)|        at Preconditions.checkFromToIndex (Preconditions.java:295)|        at Objects.checkFromToIndex (Objects.java:398)|        at (#6:1)jshell> Objects.checkFromToIndex(-4, 8, 10)|  Exception java.lang.IndexOutOfBoundsException: Range [-4, 8) out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckFromToIndex (Preconditions.java:76)|        at Preconditions.checkFromToIndex (Preconditions.java:295)|        at Objects.checkFromToIndex (Objects.java:398)|        at (#7:1)jshell> Objects.checkFromToIndex(6, 4, 10)|  Exception java.lang.IndexOutOfBoundsException: Range [6, 4) out of bounds for length 10|        at Preconditions.outOfBounds (Preconditions.java:64)|        at Preconditions.outOfBoundsCheckFromToIndex (Preconditions.java:76)|        at Preconditions.checkFromToIndex (Preconditions.java:295)|        at Objects.checkFromToIndex (Objects.java:398)|        at (#8:1)


Кроме того, в Java 16 появились перегрузки этих функций для long:




Заключение


Сегодня я рассказал про 10 интересных API, некоторые из которых появились в буквально только что вышедшей Java 16, а некоторые уже присутствуют довольно давно ещё с 9-й версии. Надеюсь, что после прочтения данной статьи вы стали более заинтересованными в миграции на последнюю версию Java. Помните, что в новых версиях Java появляются не только новые возможности, но и изменения, ломающие обратную совместимость (1, 2, 3, 4, 5, 6, 7, 8). И чем больше вы тянете с переходом с Java 8 на последнюю версию, тем сложнее вам будет осуществить этот переход.


Продолжение следует...

Подробнее..
Категории: Java , Logging , Jmh , Java15 , Java14 , Stackwalker , Java16 , Java11 , Java9 , Java8 , String , Log4j , Slf4j , Stream , Serializable

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru