Работа с проверяемыми исключениями при использовании 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/

Новые последовательные типы коллекций в JDK 21 (Sequenced Collection Types)

JEP 431: Sequenced Collections был повышен со статуса Candidate до Proposed to Target для JDK 21. В этом JEP предлагается ввести «новое семейство интерфейсов, которые представляют концепцию коллекции с элементами расположенными в четко определенной последовательности».

https://www.infoq.com/news/2023/03/collections-framework-makeover/

Spring Modulith: достигли ли мы зрелости модульности

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

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

Я считаю, что под каждую задачу нужно выбирать подходящий инструмент\технологию\архитектуру. Есть определенные субъективные критерии. Думаю, что их описание заслуживает отдельной статьи и возможно выступление на JPoint\Jocker ))

А есть ли альтернативы?

Довольно интересная альтернатива - модульный монолит (modular monolithic (modulithic) Java applications). Она тоже не является панацеей от всех бед, но в определенных кейсах может оказаться довольно привлекательной альтернативой.
https://github.com/moduliths/moduliths
https://habr.com/ru/articles/701984/

Спорно конечно, но заставляет задуматься…

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

https://youtu.be/uLp-Ht_cRk8

Примеры паттернов проектирования в JDK

Паттерны проектирования описывают типичные способы решения часто встречающихся проблем при проектировании программ.

Есть ли примеры использования паттернов в самой JDK?

В статье есть примеры: https://www.javacodegeeks.com/2011/03/design-patterns-in-jdk.html

Java JDBC и PostgreSQL

Интересная статья о взаимодействии JDBC-драйвера с PostgreSQL.
Из нее вы узнаете про:
1. Разницу между простым и расширенным протоколами PostgreSQL.
2. Почему расширенный протокол более эффективен и используется драйвером JDBC по умолчанию.
3. Почему важно закрывать PreparedStatement.
и еще много интересного ))

https://foojay.io/today/a-dissection-of-java-jdbc-to-postgresql-connections/

Spring Data JPA: проекции в запросах

Проекции в Spring Data JPA очень привлекательный инструмент для реализации запросов. Правильно подобрав проекцию можно добиться хорошей производительности.

https://habr.com/ru/companies/otus/articles/722060/

JBrainfuck — Пишем компилятор Brainfuck под Java VM

Если вы задумывались о написании своего компилятора или того как работают компиляторы, то почитать статью однозначно стоит. Примеры построены на базе ASM для генерации байт-кода. В статье разрабатывается компилятор для языка Brainfuck, но поняв принципы можно попробовать сделать свой DSL, который будет к тому же хорошо интегрироваться с существующими наработками на JVM-ных языках.

Вообще свой DSL "с меньшей болью" можно строить и на Groovy, но...мы же "не ищем легких путей"? )) Пример в статье можно рассматривать больше как хардкордный подход к вопросу с DSL.

https://habr.com/ru/articles/229267/

Что таит в себе метод clear() в Java Collection API?

В статье приведено интересное исследование последствий использования метода clear() на большой коллекции ArrayList.

В стандартной реализации этот метод удаляет содержимое из внутренней структуры данных, которая является Object[]. При этом размер самого массива не уменьшается. Соответственно чем больше у вас таких кейсов тем больше импакт.

https://dzone.com/articles/clear-details-on-java-collection-clear-api