В первой части статьи с помощью инструмента Jmix AI Assistant начато создание системы для проведения онлайн курсов.

Были сгенерированы сценарии использования (use cases), разработана UML-диаграмма в формате PlantUML для этих use cases, разработана доменная модель для системы и ее реализация на JMIX. Далее все классы разбиты по пакетам.

Продолжим эксперименты по разработке кода с помощью Jmix AI Assistant, включая следующие:

- Генерация класса, заполняющего доменную модель тестовыми данными

- Генерация REST API для модели домена, включая создание контроллеров и REST сервисов

- Генерация пользовательского интерфейса

Сборка мусора в Java отвечает за управление памятью, но не очищает ресурсы, не связанные с памятью, такие как сокеты или дескрипторы файлов.

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

Java  Cleaner API, представленный в Java 9, обеспечивает современный и эффективный механизм очистки ресурсов, когда объекты больше не доступны.

Он устраняет недостатки устаревшего метода finalize(), предлагая предсказуемый и эффективный способ управления ресурсами, не связанными с памятью: поэтому давайте совершим небольшой экскурс по методам очистки памяти от finalize до Cleaner API.

Почему статический анализ кода для Spring так важен? 72% наших пользователей JVM используют Spring в своих приложениях, особенно в таких отраслях, как производство и финансы. Почему? Spring делает программирование на Java и Kotlin более быстрым, простым и безопасным для всех, но при этом возникают уникальные проблемы.

Java разработчики часто сталкиваются с проблемой обработки очень больших наборов данных в рамках ограничений виртуальной машины Java (JVM). Когда размер кучи значительно увеличивается — часто более чем на 32 ГБ, — время паузы при сборке мусора (GC) может увеличиваться, что приводит к снижению производительности. В этой статье рассматривается, как Chronicle Queue обеспечивает хранение и эффективный доступ к набору данных размером 1 ТБ на компьютере с 64 ГБ оперативной памяти.

Эта заметка инспирирована статей на Хабре Разработка Java-проекта с ChatGPT-4: от идеи до реализации [1]. После ее прочтения автор начал экспериментировать в разработке ПО с различными AI ассистентами.

Увидев статью блога Jmix AI Assistant — ваш помощник в освоении Jmix, решил реализовать с помощью Jmix AI Assistant приложение аналогичное приведенному в статье [1].

Главное отличие от указанной статьи в том, что вся разработка будет вестись с помощью одного инструмента Jmix AI Assistant без использования сторонних генераторов кода.

Одной из наиболее важных проблем при создании распределенных приложений является вопрос представления данных. Мы должны убедиться, что данные, отправленные компонентом «удаленному» компоненту (т. е. компоненту, который является частью другого процесса), будут получены правильно с теми же значениями. 

Это может показаться простым, но помните, что взаимодействующие компоненты могут быть написаны на совершенно разных языках. Ситуация усложняется еще больше, если учесть, что разные аппаратные/системные архитектуры, скорее всего, имеют различные способы представления «одинаковых» значений. Простого копирования байтов из одного компонента в другой недостаточно. Даже в Java, где мы можем считать себя «защищенными» от такого рода ситуаций, нет требования, чтобы две разные реализации JVM или разные версии от одного производителя использовали одно и то же внутреннее представление для объектов.

Наиболее распространенным решением этой проблемы является определение «канонического» представления данных, которое будет понятно между процессами — даже между языками программирования — и перевод данных в этот формат перед отправкой, а затем обратно в собственный формат получателя после получения. 

Существует несколько таких «форматов передачи», начиная от текстовых стандартов, таких как YAML, JSON или XML, до бинарных вариантов, таких как Protobuf, которые включают метаданные или являются полностью неструктурированными.

В компании Chronicle Software разработан ряд библиотек для поддержки создания приложений, оптимизированных для обмена сообщениями с низкой задержкой, в основном в сфере финансовых услуг. 

В этой статье вы узнаете, как использовать Spring for GraphQL в своем приложении Spring Boot. 

Spring for GraphQL — относительно новый проект. Версия 1.0 была выпущена несколько месяцев назад. До этого релиза нам приходилось подключать сторонние библиотеки, чтобы упростить реализацию GraphQL в приложении Spring Boot. Я уже описал два альтернативных решения в своих предыдущих статьях. В следующей статье вы узнаете о проекте GraphQL Java Kickstart. В другой статье вы увидите, как создавать более сложные запросы GraphQL с помощью библиотеки Netflix DGS.

Мы будем использовать очень похожую схему и модель сущностей, как и в этих двух статьях о Spring Boot и GraphQL.

Если вы хотите попробовать сделать это самостоятельно, вы всегда можете посмотреть на мой исходный код. Для этого вам нужно клонировать мой  репозиторий GitHub. Затем просто следуйте моим инструкциям.

При создании приложений на Java мы сильно зависим от внешних библиотек и фреймворков. И каждый импортируемый пакет Java, скорее всего, также зависит от большего количества библиотек. Это означает, что количество Java-пакетов, включенных в ваше приложение, часто не совсем прозрачно.

Эти вложенные (транзитивные) зависимости создают проблему, заключающуюся в том, что вы как разработчик, вероятно, не знаете всех библиотек, которые на самом деле используете.

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

Но что, если вы передаете свое Java-приложение клиенту?

Как они узнают, какие зависимости включены?

Что еще важнее, как они могут проверить, не уязвимы ли эти зависимости для проблем безопасности?

Ответом является спецификация программного обеспечения SBOM (software bill of materials).

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

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

Узнайте, как использовать пейджер pspg с базами данных MariaDB для визуализации и эффективного взаимодействия с данными при выполнении задач DevOps.

Я не являюсь противником GUI. На самом деле, я написал три книги о разработке графического веб-интерфейса с помощью Java. Однако мне также нравится интерфейс командной строки (CLI), особенно текстовые пользовательские интерфейсы. 

После года изучения MariaDB и мира DevOps я открыл для себя и поэкспериментировал со многими текстовыми инструментами CLI, о существовании которых я даже не подозревал. Эти инструменты особенно полезны при подключении к удаленным серверам без графического интерфейса.

Одним из специальных инструментов CLI, который я часто использую, является SQL-клиентmariadb (или mysq в мире MySQL) — программа CLI, используемая для подключения к базам данных, совместимым с MariaDB. С ее помощью вы можете отправлять SQL-запросы и другие команды на сервер базы данных.

В этой статье вы узнаете, как расширение JPAstreamer Quarkus упрощает выполнение типо‑безопасных запросов Hibernate без излишней многословности и сложности.

CRaC (Coordinated Restore at Checkpoint) — это проект OpenJDK, разработанный Azul для решения проблемы «медленного» запуска виртуальной машины Java в микросервисной среде.

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

В механизме восстановления контрольной точки (checkpoint-restore) нет ничего нового, и большинство из вас уже знают и используют его ежедневно. 

Если вы работаете на ноутбуке и закрываете крышку, операционная система обнаруживает это и сохраняет текущее состояние на диск. Как только вы снова открываете крышку, операционная система восстанавливает сохраненное состояние с диска.
CRaC предоставляет тот же механизм, но для JVM и вашего запущенного приложения.

Вы запускаете свое приложение, применяете к нему некоторую рабочую нагрузку (чтобы убедиться, что важные части вашего кода будут затронуты и оптимизированы JVM), а затем создаете контрольную точку. Это приведет к закрытию всех открытых ресурсов, таких как открытые файлы и сокетные соединения, а затем сохранит состояние JVM, включая ваше приложение, на диск.

После этого вы сможете восстанавливать состояние JVM, включая состояние вашего приложения, из этой сохраненной контрольной точки так часто, как вам захочется.

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

Я в ударе! После того, как я написал о разрушении вашей базы данных и обертывании идентификатора транзакции, здесь я пишу о повреждениях, вызванных CHECK ограничениями! 

Поверьте мне, я не хочу разрушать базы данных PostgreSQL. Просто это сообщение в Твиттере привлекло мое внимание и вызвало воспоминания о других сообщениях о CHECK ограничениях, вызвавших проблемы.

JDK 20, третий не-LTS-релиз после JDK 17, достиг начальной фазы релиз-кандидата, как заявил Марк Рейнхольд, главный архитектор Java Platform Group в Oracle. Основной репозиторий исходного кода, форкнутый в стабилизационный репозиторий JDK в середине декабря 2022 г. (Rampdown Phase One), определяет набор функций для JDK 20. Критические ошибки, такие как регрессии или серьезные функциональные проблемы, могут быть устранены, но должны быть одобрены в процессе Fix-Request. Согласно графику выпуска, JDK 20 будет официально выпущен 21 марта 2023 года. Стоит отметить, что JEP 438 был добавлен в набор функций в начале марта 2023 года.

В сентябре 2023 года планируется выпустить общедоступный и следующий выпуск LTS В настоящее время в качестве целевых для JDK 21 предлагается два (2) JEP.

Также можно предположить, какие дополнительные JEP могут быть включены в JDK 21, основываясь на ряде проектов и кандидатов JEP.

Через два месяца после первого коммита в октябре 2022 года Питер Верхас, старший архитектор EPAM Systems, выпустил версию 2.0.0 SourceBuddy, новой утилиты, которая компилирует динамически исходный код Java, заданный в строке или файле, в файл класса. 

Утилит SourceBuddy требует Java 17 и представляет собой упрощенный фасад для компилятора javac, который обеспечивает ту же функциональность.

Версия 2.0.0 поддерживает комбинацию скрытых и нескрытых классов во время компиляции и выполнения. Кроме того, был упрощен API, включая критические изменения, такие как изменение метода loadHidden() на метод hidden(), поэтому и выпущен новый основной релиз. Полный обзор изменений для каждой версии доступен в документации по выпускам на GitHub.

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

В этом посте вы узнаете:

Как сохранить модель PyTorch в формате обмена

Как использовать Netron для создания графического представления.

Поскольку мы все с нетерпением ждем скорого выпуска JDK 20, список функций, которые появятся в JDK 21 этой осенью, также постепенно проясняется.

Сегодня мы рассмотрим тему того, что принесет следующий LTS релиз JDK 21.

Из этой статьи вы узнаете о некоторых не очень известных, но полезных библиотеках Java. Это вторая статья из серии «Полезное и неизвестное». Предыдущая описывала несколько привлекательных, но малоизвестных возможностей Java. Подробнее об этом можно прочитать здесь.

Сегодня мы сосредоточимся на библиотеках Java. Обычно мы используем в своих проектах несколько внешних библиотек — даже если не включаем их напрямую. Например, Spring Boot поставляется с определенным набором зависимостей, включенным стартерами. Если мы включаем, например, spring-boot-starter-test, то одновременно мы включаем такие библиотеки, как mockito, junit-jupiter или hamcrest. Конечно, это известные библиотеки для сообщества.

На самом деле существует множество различных Java‑библиотек. Обычно мне не нужно использовать многие из них (или даже они мне не нужны) при работе с такими фреймворками, как Spring Boot или Quarkus.

Однако есть несколько очень интересных библиотек, которые могут пригодиться везде. Возможно, вы не слышали ни об одной из них. Я собираюсь представить 5 моих любимых «полезных и неизвестных» Java‑библиотек. Давай начнем!

В этой статье вы прочитаете о лучших практиках запуска Java-приложений в Kubernetes. Большинство из этих рекомендаций будут справедливы и для других языков. 

Однако я рассматриваю все правила в рамках характеристик Java, а также показываю решения и инструменты, доступные для приложений на базе JVM. 

Некоторые из этих рекомендаций по Kubernetes навязаны дизайном при использовании самых популярных Java-фреймворков, таких, как Spring Boot или Quarkus. Я покажу вам, как эффективно использовать их для упрощения жизни разработчиков.

Вы можете использовать это руководство для получения практической информации о том, как найти и установить последнюю версию Java, понять различия между дистрибутивами Java (Adoptium, AdoptOpenJdk, OpenJDK, OracleJDK и т. д.), а также получить обзор функций языка Java, включая версии 8–19.