Java guru

Смерть от тысячи микросервисов

Статья заставляет задуматься ))

Пару фактов: Dropbox, Twitter/X, Facebook, Instagram, Shopify, Stack Overflow — эти и другие компании начинали как монолитные базы кода. Многие по сей день имеют в своей основе монолит. Shopify по-прежнему остается монолитом Rails. WhatsApp стал сверхновой благодаря монолиту Erlang и 50 инженерам. Что касается серверов, WhatsApp предпочитает использовать меньшее количество серверов и вертикально масштабировать каждый сервер в максимально возможной степени. Instagram был приобретен за миллиарды — с командой из 12 человек.

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

Java Records

Java Record-ы появились в Java 12 как preview feature (JEP 359), а финальный релиз был в Java 16 (JEP 395). В разных источниках обычно приводят примеры их использования для описания DTO (Data Transfer Objects), но сфера их применения гораздо шире. В статье автор приводит разные примеры. Мне понравился пример реализации стейт машины «State implementation”.

https://www.infoq.com/articles/exploring-java-records/

Обработка исключений в Java в функциональном стиле

В Java начиная с версии 8 появились новые возможности в виде функциональных интерфейсов и потоков (Stream API).Однако применение функционального стиля на практике осложняется тем, что все стандартные функциональные интерфейсы из пакета java.util.function не объявляют проверяемых исключений (являются checked exception unaware).
В данной статье автор предоставит информацию о собственной библиотеке для обработки исключений (Exception) в функциональном стиле.

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

Потоковый обмен в распределённых системах и использование реактивных потоков в нереактивных приложениях: опыт «Магнита»

Интересный опыт использования реактивных потоков. Рассматриваются три решения, которые позволяют реализовать потоковый обмен данными из БД между распределёнными приложениями:
1 Реализация с использованием hibernate
2 Реализация с использованием mybatis
3 Ограничение скорости обмена с использованием механизма обратного давления («backpressure») и библиотеки Bucket4j

https://habr.com/ru/companies/magnit/articles/726090/

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

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

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

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

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

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

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

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

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

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

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

Java JDBC и PostgreSQL

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

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

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

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

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

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

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

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

https://youtu.be/uLp-Ht_cRk8

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

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

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

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

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

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

Новые последовательные типы коллекций в 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/

Поиск утечек потоков (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/

А вы знали что можно делать через 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/

Суффикс 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

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

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

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

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

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

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

В рассылке 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

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

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

VM Options Explorer

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

https://chriswhocodes.com/

The Polyglot Developer Reference

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

https://codethesaur.us/