Свой Spliterator

Многие из вас активно пользуются Stream API из Java 8, но не всем приходилось создавать свои Spliterator-ы. В статье очень хорошо разбирается процесс написания своего Spliterator-а. Мне особенно понравился пример создания для любой нестандартной коллекции (ещё пример — org.json.JSONArray), которая умеет быстро вернуть длину и элемент по порядковому номеру.

public class XmlStream {
static Stream<Node> of(NodeList list) {
return IntStream.range(0, list.getLength()).mapToObj(list::item);
}
}

https://habr.com/ru/post/256905/

Выпуск стандартной Си-библиотеки Cosmopolitan 2.0, развиваемой для переносимых исполняемых файлов

Этот пост не про Java. Извините, но я просто не удержался. Для меня она настоящее открытие.

Если вы думали, что только в Java возможна переносимость между разными операционными системами, то вы ошибались. Your build-once run-anywhere c library!!!
https://justine.lol/cosmopolitan/

Опубликован выпуск проекта Cosmopolitan 2.0, развивающего стандартную Си-библиотеку и универсальный формат исполняемых файлов, который можно использовать для распространения программ для разных операционных систем без использования интерпретаторов и виртуальных машин. Получаемый при помощи компиляции в GCC и Clang результат компонуется в статически связываемый универсальный исполняемый файл, который пригоден для запуска в любом дистрибутиве Linux, macOS, Windows, FreeBSD, OpenBSD, NetBSD и даже вызова из BIOS. Код проекта распространяется под лицензией ISC (упрощённый вариант MIT/BSD).

Контейнер для формирования универсальных исполняемых файлов основан на совмещении специфичных для разных операционных систем сегментов и заголовков (PE, ELF, MACHO, OPENBSD) в одном файле, комбинируя в нем несколько разных форматов, используемых в Unix, Windows и macOS. Для обеспечения запуска одного исполняемого файла в Windows и Unix-системах применяется трюк, связанный с кодированием файлов Windows PE в виде shell-скрипта, пользуясь тем, что Thompson Shell не использует маркер скриптов "#!". Для создания программ, включающих несколько файлов (компоновки всех ресурсов в один файл), поддерживается формирование исполняемого файла в виде специально оформленного ZIP-архива.

https://github.com/jart/cosmopolitan/releases/tag/2.0

Статический анализ кода в современной Java-разработке

Многостраничные гайды по оформлению кода, правильных инструментах и библиотеках по факту не работают. Люди в принципе не любят читать документацию. Автор статьи выражается более радикально по поводу таких гайдов ))

Выход из ситуации использовать различные автоматизированные средства валидация. В статье собрана неплохая подборка, которую однозначно стоит попробовать. Подключать ли все сложный вопрос. С одной стороны больше мнений по качеству кода, а с другой стороны замедление (доп. время на проверки). Нужно искать золотую середину. Я думаю, что если на одной чаше качество кода, а на другой скорость, то я скорее отдам большее предпочтение качеству, но возможно не каждый заказчик со мной согласится. Им нужно как всегда быстро и качественно )))
https://habr.com/ru/post/680018/

JUnit расширение DbChange

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

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

https://habr.com/ru/post/684692/ 

Вышла Java 19

В этот релиз попало более двух тысяч закрытых задач и 7 JEP'ов.

https://habr.com/ru/post/689344/

Обобщенное программирование – обзор реализаций

В статье дается довольно занимательное сравнение поддержки обобщенного программирования в C++, Java, C#(.Net). Наилучшего подхода не существует, любой подход – это всегда компромисс, при котором одними преимуществами жертвуют ради других.

https://habr.com/ru/company/piter/blog/656377/

Better Java logging, inspired by Clojure and Rust

Недавно наткнулся на интересную статью про логирование. Там сравниваются подходы к логированию в Clojure, Rust и Java. Самое вкусное в этой статье - это попытка автора реализовать в Java более лучший способ логирования. Он в реализации использует новые фичи из последних версий Java и интересно проследить ход его мысли. Он по шагам добавляет новый функционал.

С практической точки зрения я не во всем согласен с автором. Особого профита от namespace-ов я особо не вижу. В моем представлении реализация получилась достаточно перегруженной и самое главное нет возможности отключить не нужные фичи. Возможно стоит доработать решение. Не нужно забывать еще и про GG. В частности в том же log4j есть режим "garbage free".

Про log4j есть режим "garbage free" - https://logging.apache.org/log4j/2.x/manual/garbagefree.html

https://mccue.dev/pages/9-25-22-better-java-logging

Shift Left Approach for API Standardization

Как я уже писал в одном из прошлых постов разработчики не любят читать "длинных инструкций" и нужны автоматизированные средства проверки. С разработкой API тоже беда. Вы можете разработать стандарты и взять за основу Microsoft REST API Guidelines https://github.com/Microsoft/api-guidelines или Google API design guide https://cloud.google.com/apis/design/ или посмотреть примеры на API Stylebook http://apistylebook.com/ но чем больше мануал тем меньше вероятность что прочтут до конца и самое главное правильно поймут.

Решение: воспользоваться автоматизацией. Если разговор про OpenAPI, то есть целый класс инструментов линтеров https://nordicapis.com/8-openapi-linters/

В статье приводится пример для Zally. У данного инструмента есть также Gradle plugin. https://github.com/thiyagu06/zally-gradle-plugin

https://www.infoq.com/articles/shift-left-api/

Работа с проверяемыми исключениями при использовании Stream-ом

Я думаю, что многих из вас раздражают проверяемые исключения "всплывающие" при попытке выстроить "красивый код" со Stream-ами. Ряд библиотек приходят к нам на помощь и предлагают свои решения. В статье приводится пример проблемы и того как разные библиотеки предлагают ее решать. Решение предлагаемое в библиотеке Vavr мне кажется более полным так как позволяет в функциональном стиле описать в том числе и обработку исключения.
https://blog.frankel.ch/exceptions-lambdas/

Настраиваем память JVM-приложения в Kubernetes

Я думаю, что многие из вас сталкиваются в работе либо с Kubernetes либо OpenShift и как известно там есть особенности в том сколько "видит" памяти ваше JVM приложение. В статье неплохо раскрывается эта тема и самое главное без лишней "воды". Также предлагается скрипт для автоматизации. Думаю, что в работе будет однозначно полезно.
https://habr.com/ru/company/domclick/blog/691240/

Apache Kafka 3.3 заменяет ZooKeeper новым протоколом консенсуса KRaft

Apache Software Foundation выпустила Apache Kafka 3.3.1 со множеством новых улучшений. В частности, это первый выпуск, который помечает протокол консенсуса KRaft (Kafka Raft) как готовый к промышленной эксплуатации.

KRaft — это протокол консенсуса, разработанный для управления метаданными непосредственно в Apache Kafka. Это значительно упрощает архитектуру Kafka, возлагая ответственность за метаданные на саму Kafka без необходимости использования стороннего инструмента, такого как Apache ZooKeeper. KRaft улучшает масштабируемость и отказоустойчивость разделов, а также упрощает развертывание Apache Kafka.

https://developer.confluent.io/learn/kraft/

Archunit инструмент автоматизации проверки качества архитектуры.

Сейчас все помешаны на автоматизации и стараются ее применить во всем. Я достаточно давно наткнулся на очень интересный проект Archunit. Использовать его для валидации промышленного кода пока не доводилось, но выглядит он достаточно интересно. Рекомендую обратить внимание.

https://archunit.org/

The Polyglot Developer Reference

Недавно наткнулся на интересный инструмент позволяющий сравнивать возможности разных языков программирования. Как минимум можно сравнивать там разные версии Java, но сравнения возможностей Java с другими языками тоже достаточно интересны. Я думаю, что экосистему определяет не только синтаксис языка, но так же очень важную роль играют и доступные фреймворки и библиотеки. Думаю было бы интересно получить такое же сравнение для наиболее типовых кейсов. Например сравнение реализации типовых REST, gRPC и интеграций через Kafka.

https://codethesaur.us/

VM Options Explorer

Chris Newland, один из авторов книги "Optimizing Java - Practical Techniques for Improving JVM Application Performance", создал ресурс на котором собрал информацию по опциям JVM и полезным ссылкам.

https://chriswhocodes.com/

Может ли Java-приложение использовать больше памяти, чем размер кучи?

В этой статье хорошо раскрыта тема устройства памяти JVM. Также затронута тема инструментов диагностики и параметры JVM.
Лично для меня там была интересна тема про Native Memory Tracking.
https://habr.com/ru/company/otus/blog/705982/

В рассылке OpenJDK предложен новый проект Galahad.

В рамках проекта планируется внедрение в OpenJDK технологий GraalVM, связанных с Java, а именно JIT-компилятора GraalVM (полностью написанного на Java) в качестве альтернативы существующему JIT-компилятору Hotspot. Затем, следующим шагом будет использование AOT-компилятора GraalVM для компиляции JIT-компилятора, а позднее – портирование Native Image в качестве общего решения для любых Java-приложений.

Начиная с JDK 20, GraalVM будет выходить 2 раза в год (а не 4, как раньше). Следующая версия GraalVM выйдет одновременно с JDK 20 в марте и будет называться GraalVM for JDK 20.

https://mail.openjdk.org/pipermail/discuss/2022-December/006164.html

Что писать в комментариях к коду?

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

Я бы рекомендовал рассматривать комментарии как инструмент позволяющий дополнять "историю" рассказываемую кодом т.е. комментарии не должны пересказывать код.

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

UPD. Я подумал, что этот подход может технически хорошо вписаться\дополнить парадигму разработки через тестирование (test-driven development, TDD). По факту при TDD вы сначала в тестах (на уровне кода) описываете поведение своего кода и уже потом приступаете к реализации этого поведения. В этом пазле как раз не хватает начальной постановки т.е. ради чего все это делается. Технически можно начать с комментария к классу, в котором будет зафиксировано какую проблему должен решать класс без уточнения того как он этого добьется (ответ на вопрос "Почему?").

https://dzone.com/articles/why-should-i-comment-my-code

Суффикс Impl и префикс I зло!

Я ненавижу суффикс Impl в именах классов и префикс I в именах интерфейсов. Первый появился с легкой руки IBM, а второй Microsoft. Оба чужды идеологии ООП и Java в частности. В Java этот визуальный шум "занесли" выходцы из других языков. Еше хуже когда в одном проекте их начинают мешать друг с другом.

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

Для клиента используемый тип данных должен быть прозрачным и ему должно быть безразлично общается он с интерфейсов или конкретной реализацией. I создает лишь визуальный шум.

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

https://octoperf.com/blog/2016/10/27/impl-classes-are-evil/#why-impl-is-bad

А вы знали что можно делать через pg_logical_emit_message() в PostgreSQL?

Сегодня прочитал очень занимательную статью про интересные способы использования pg_logical_emit_message(). На Oracle я такое никогда не делал и был приятно удивлен. Не знаю на сколько такое решение производительно, но звучит очень соблазнительно.

Через pg_logical_emit_message() можно писать в write-ahead log (WAL) базы и есть стандартный открытый апи для чтения из него (log-based change data capture CDC).

Способы использования:
1. Outbox Pattern. Если коротко, то он позволяет решить проблему с распределенными транзакциями. Например изменения в базе и уведомление через кафку смежников.
2. Логирование. Для меня пока выглядит слишком…экзотически, но возможно нужно привыкнуть к этой мысли и попытаться найти оправдания такому подходу. Еще помедитирую на эту тему.
3. Логи аудита. Пока кажется, что это частный случай пункта 2.
4. Advancing Replication Slots. Репликация для баз на одной машине. Возможно есть кто такое использует.

Краткий итог. Лично для меня больше интересен пункт 1. Я о таком даже не думал. Стоит попробовать и посмотреть на сколько это пригодно под нагрузками.
https://www.infoq.com/articles/wonders-of-postgres-logical-decoding-messages/

Поиск утечек потоков (Thread Leaks) с помощью JDK Flight Recorder и немного SQL

Я думаю, что многие уже успели по достоинству оценить возможности JFR и JDK Mission Control. Они очень помогают в анализе. В статье освещается еще один интересный инструмент JFR Analytics. Он позволяет использовать SQL подобный язык при анализе JFR. Учитывая декларативную природу SQL звучит заманчиво.

https://www.morling.dev/blog/finding-java-thread-leaks-with-jdk-flight-recorder-and-bit-of-sql/