Hibernate 8: проверки версий при конкурентных обновлениях
Оптимистическая блокировка должна обнаружить, что между чтением и записью сущность уже изменил другой запрос. Детали реализации и поведение базы здесь имеют значение.
В разборе изменений Hibernate 8 Beta2 команда описывает усиленные проверки версий: они учитывают ситуации, в которых конкурентное изменение раньше могло остаться незамеченным. Поддержку блокировки по версии получили StatelessSession и EntityAgent из Jakarta Persistence.
Ещё одно изменение касается параллельных upsert в StatelessSession: обработка учитывает гонку вставки. Для разделения данных по арендаторам их идентификаторы последовательно включаются в SQL изменения данных.
Это повод добавить к проверке миграции сценарии с одновременными обновлениями и вставками. Ветка Hibernate 8 пока тестовая; после описанной Beta2 уже вышла Beta3. Возможности из заметки полезно оценивать вместе с актуальным руководством по миграции.
Для нескольких сервисов бывает достаточно видеть задержки, ошибки, память и перезапуски. В руководстве по StatLite показана панель, которая собирает эти данные из Spring Boot Actuator.
StatLite запускается одним Go-бинарником и хранит историю в SQLite. На стороне приложения нужны Actuator, Micrometer с prometheus-registry и доступные сборщику endpoints health и prometheus. Отдельный сервер Prometheus для этого варианта не требуется.
В конфигурации задаются адрес приложения, интервал опроса и тайм-аут. Панель по умолчанию привязана к localhost; доступ к Actuator тоже стоит ограничить сетью и аутентификацией.
Решение рассчитано на небольшой набор приложений. Для распределённых трассировок, централизованных журналов, сложных запросов к метрикам и маршрутизации оповещений понадобится более широкая система. В статье есть готовый демонстрационный Spring Boot-сервис с генератором трафика.
Имя модуля и его зависимости уже описаны в Java-коде. Рафаэль Винтерхальтер, автор Byte Buddy, предлагает использовать эту информацию и для сборки.
В знакомстве с Jenesis основным описанием проекта становится module-info.java. Дополнительные сведения, например главный класс, задаются тегами в Javadoc. Сам инструмент хранится в репозитории как Java-исходники и запускается на JDK 25+:
java build/jenesis/Make.java
Команда pin фиксирует версии зависимостей и контрольные суммы. Шаги сборки кешируются по входным данным, а для тестов инструмент определяет, какие из них затрагивает изменение.
Для знакомства не обязательно сразу переводить проект на модули: Jenesis умеет читать и pom.xml. В статье есть примеры многомодульной сборки, общего кеша и генерации кода. Перед переходом остаётся проверить, как инструмент справляется с особыми шагами именно вашей сборки.
Hibernate Validator 9.2: проверки паролей через аннотации
В первой бете Hibernate Validator 9.2 появились @PasswordStrength, @NotCompromised и @PasswordPolicy. Они позволяют проверять стойкость пароля, наличие в известных утечках и соблюдение набора правил.
В описании релиза есть важная подробность: готового оценщика стойкости и сервиса проверки утечек библиотека не предоставляет. Приложение подключает свои реализации PasswordStrengthEstimator и CompromisedPasswordChecker.
Все три ограничения считают null допустимым значением. Обязательное поле нужно дополнительно пометить @NotNull или @NotBlank.
PasswordPolicy объединяет правила в повторно используемый класс. Каждое нарушенное правило создаёт собственную ошибку валидации, поэтому можно показать, какие требования не выполнены.
Это бета; многие новые API ещё экспериментальные. Примеры подключения сервисов в статье стоит рассматривать как основу для знакомства с интерфейсами.
Почему javac разрешает удалить Integer из Set<Short>
Метод remove(Object) принимает любой объект. Поэтому такой код компилируется, но оставляет элемент в коллекции:
Set<Short> values = new HashSet<>();
values.add((short) 1);
values.remove(1);
В последней строке 1 упаковывается в Integer. В наборе лежит Short, и равными эти объекты не считаются.
В разборе Error Prone показано, как находить подобные ошибки при компиляции. Инструмент подключается к javac и использует сведения о типах: проверка CollectionIncompatibleType замечает несовместимый аргумент коллекции.
Другой пример — YYYY вместо yyyy в формате даты: год недели может отличаться от календарного в конце декабря. Проверка MisusedWeekYear помогает поймать и эту ошибку. Для правил своей команды можно написать BugChecker, а повторяющиеся замены описать Java-шаблонами Refaster.
В JavaDoc предлагают отдельный тег для предупреждений
Совет по использованию метода или важное ограничение легко потерять внутри длинного описания. Для JDK 28 предлагают тег @note, который выделяет такие фрагменты при генерации документации.
В заметке OpenJDK Quality Outreach показаны два варианта: встроенная заметка с вертикальной полосой и блочная с отдельным заголовком. Заголовок можно изменить, например на Caution:
Атрибуты kind и id позволяют добавить CSS-класс и идентификатор HTML-элемента. Предложение также предусматривает настройку собственных тегов через параметры javadoc.
Пока это предлагаемые изменения для JDK 28. Пример полезен для знакомства с будущим форматом; использовать его как поддерживаемый синтаксис в документации проекта на JDK 27 рано.
JDK 27 поддерживает гибридный обмен ключами: группа X25519MLKEM768 объединяет классическую кривую X25519 и постквантовый алгоритм ML-KEM. Она включена по умолчанию, но для её использования поддержку должны иметь обе стороны соединения.
В обзоре Java Security Sean Mullan объясняет и другие изменения TLS. Цепочки сертификатов теперь могут передаваться со сжатием zlib, а редко используемые группы ffdhe6144 и ffdhe8192 убраны из списка по умолчанию.
Для настройки групп есть свойство jdk.tls.namedGroups и метод SSLParameters.setNamedGroups(). Удалённые из стандартного списка группы можно явно включить, если они нужны для совместимости.
При переходе стоит проверить соединения с реальными клиентами и серверами. Поддержка новой группы в JDK ещё не означает, что каждое соединение её согласует: результат зависит и от возможностей второй стороны.