Hibernate экономит код. Базе данных на это плевать
ORM отлично убирает повторяющийся persistence-код и связывает данные с объектной моделью. Но SQL, сеть и materialization никуда не деваются — просто становятся менее заметны в Java-коде. Магия закончилась на аннотациях.
100 orders + lazy collection в цикле: 1 root query + до 100 secondary selects = до 101 SQL.
Две to-many коллекции по 10 и 20 элементов: JOIN способен вернуть до 200 rows на parent. Hibernate ORM User Guide также фиксирует: EAGER не гарантирует один JOIN, несколько bags могут вызвать MultipleBagFetchException, а IDENTITY отключает JDBC insert batching.
Поэтому я смотрю SQL statements, rows, план через PostgreSQL EXPLAIN и размер persistence context/flush, а не гадаю по красивым entities. Только потом выбираю JOIN FETCH, entity graph, batch fetch, DTO или native SQL.
Hibernate — инструмент. Делать вид, что он отменил SQL, — дорогая иллюзия.
#Java #Hibernate #JPA #SQL
ORM отлично убирает повторяющийся persistence-код и связывает данные с объектной моделью. Но SQL, сеть и materialization никуда не деваются — просто становятся менее заметны в Java-коде. Магия закончилась на аннотациях.
100 orders + lazy collection в цикле: 1 root query + до 100 secondary selects = до 101 SQL.
Две to-many коллекции по 10 и 20 элементов: JOIN способен вернуть до 200 rows на parent. Hibernate ORM User Guide также фиксирует: EAGER не гарантирует один JOIN, несколько bags могут вызвать MultipleBagFetchException, а IDENTITY отключает JDBC insert batching.
Поэтому я смотрю SQL statements, rows, план через PostgreSQL EXPLAIN и размер persistence context/flush, а не гадаю по красивым entities. Только потом выбираю JOIN FETCH, entity graph, batch fetch, DTO или native SQL.
Hibernate — инструмент. Делать вид, что он отменил SQL, — дорогая иллюзия.
#Java #Hibernate #JPA #SQL
JDK 27 заморозила scope — пора ломать стенд
16 июля JDK 27 перешла в Rampdown Phase Two: feature set frozen, новых JEP не будет. Initial RC — 6 августа, Final RC — 20 августа, GA — 15 сентября.
В scope 8 JEP. Для production особенно заметны G1 по умолчанию во всех окружениях, Compact Object Headers по умолчанию, JFR in-process redaction и post-quantum hybrid TLS 1.3.
Draft release notes от 17 июля фиксируют removal экспериментального JVMCI, связанных модулей/flags и
Действие сейчас: latest EA в compatibility CI; проверить flags, agents, heap/latency, JFR pipeline, TLS и зависимости от JVMCI. Нести EA в production ради галочки — херовый release plan. Pilot — после Final RC и своих regression-тестов.
#Java #JDK27 #JVM #новости
16 июля JDK 27 перешла в Rampdown Phase Two: feature set frozen, новых JEP не будет. Initial RC — 6 августа, Final RC — 20 августа, GA — 15 сентября.
В scope 8 JEP. Для production особенно заметны G1 по умолчанию во всех окружениях, Compact Object Headers по умолчанию, JFR in-process redaction и post-quantum hybrid TLS 1.3.
Draft release notes от 17 июля фиксируют removal экспериментального JVMCI, связанных модулей/flags и
-XX:+UseGraalJIT.Действие сейчас: latest EA в compatibility CI; проверить flags, agents, heap/latency, JFR pipeline, TLS и зависимости от JVMCI. Нести EA в production ради галочки — херовый release plan. Pilot — после Final RC и своих regression-тестов.
#Java #JDK27 #JVM #новости
Радар июля: версии приехали, готовность — как обычно
Новая версия сама по себе никого не спасает. Она просто приносит новый набор рисков, пока команда радостно читает changelog по диагонали.
По данным OpenJDK, JDK 26 достиг GA 17 марта: HTTP/3, снижение synchronization overhead G1, AOT cache с любым GC; Structured Concurrency — preview. JDK 27 GA запланирован на 15 сентября.
Официальный анонс Spring Boot 4.1.0 от 10 июня называет 5 highlights; требования — Java 17+, совместимость до Java 26 и Spring Framework 7.0.8+.
Release notes Apache Kafka 4.3.1 от 25 июня содержат 11 JIRA issues, включая 8 bugs; анонс благодарит 23 contributors. Среди важных fixes: KAFKA-20616 (RocksDB native-memory/OOM), 20663 (stale changelog offset), 20673 (Admin API hang).
Мои действия без релизного цирка: JDK — compatibility CI; Boot — migration backlog; Kafka 4.3.0 — patch после upgrade review.
#Java #JDK #SpringBoot #Kafka #новости
Новая версия сама по себе никого не спасает. Она просто приносит новый набор рисков, пока команда радостно читает changelog по диагонали.
По данным OpenJDK, JDK 26 достиг GA 17 марта: HTTP/3, снижение synchronization overhead G1, AOT cache с любым GC; Structured Concurrency — preview. JDK 27 GA запланирован на 15 сентября.
Официальный анонс Spring Boot 4.1.0 от 10 июня называет 5 highlights; требования — Java 17+, совместимость до Java 26 и Spring Framework 7.0.8+.
Release notes Apache Kafka 4.3.1 от 25 июня содержат 11 JIRA issues, включая 8 bugs; анонс благодарит 23 contributors. Среди важных fixes: KAFKA-20616 (RocksDB native-memory/OOM), 20663 (stale changelog offset), 20673 (Admin API hang).
Мои действия без релизного цирка: JDK — compatibility CI; Boot — migration backlog; Kafka 4.3.0 — patch после upgrade review.
#Java #JDK #SpringBoot #Kafka #новости
Обновили Java? Проверьте, что новая версия запущена
OpenJDK advisory от 21 июля сообщает об уязвимостях в Java 8, 11, 17, 21, 25 и 26. В основной таблице их 11, самая серьёзная получила 7,5 балла из 10. Отдельное обновление нужно приложениям на JavaFX.
Главная ловушка: команда меняет версию в настройках, а работающий сервис остаётся на старой Java. Без перезапуска риск никуда не делся.
Что сделать:
— найти Java во всех сервисах, контейнерах, виртуальных машинах и фоновых задачах;
— поставить исправленную сборку от своего поставщика;
— пересобрать образы и перезапустить сервисы;
— проверить используемые соединения, изображения и JavaFX;
— снова выполнить
Зелёная сборка — ещё не доказательство обновления. Доказательство — новая версия Java в каждом реально работающем процессе.
#Java #security #JDK #новости
OpenJDK advisory от 21 июля сообщает об уязвимостях в Java 8, 11, 17, 21, 25 и 26. В основной таблице их 11, самая серьёзная получила 7,5 балла из 10. Отдельное обновление нужно приложениям на JavaFX.
Главная ловушка: команда меняет версию в настройках, а работающий сервис остаётся на старой Java. Без перезапуска риск никуда не делся.
Что сделать:
— найти Java во всех сервисах, контейнерах, виртуальных машинах и фоновых задачах;
— поставить исправленную сборку от своего поставщика;
— пересобрать образы и перезапустить сервисы;
— проверить используемые соединения, изображения и JavaFX;
— снова выполнить
java -version и проверку безопасности.Зелёная сборка — ещё не доказательство обновления. Доказательство — новая версия Java в каждом реально работающем процессе.
#Java #security #JDK #новости
Один таймер не спасает запрос к базе
Пять секунд в настройке ещё не гарантируют, что запрос остановился и освободил соединение.
Для обычного SQL-запроса Java задаёт отдельный срок. После его превышения driver возвращает SQLTimeoutException и пытается отменить работу. Это ещё не доказательство, что сервер базы уже остановился.
Для полностью зависшей сети действует аварийный предел. В терминах JDBC network timeout помечает connection closed — проще говоря, Java закрывает соединение. Oracle рекомендует делать этот срок длиннее обычного времени на запрос.
PostgreSQL разделяет долгий запрос, ожидание занятой записи и забытую открытую транзакцию. Им нужны разные пределы.
Мой порядок:
— срок всей пользовательской операции;
— меньший срок для SQL;
— ещё меньший — для ожидания блокировки;
— аварийное закрытие сети последним.
После ошибки проверяю, что запрос остановлен, а соединение вернулось в пул.
#Java #JDBC #PostgreSQL #reliability
Пять секунд в настройке ещё не гарантируют, что запрос остановился и освободил соединение.
Для обычного SQL-запроса Java задаёт отдельный срок. После его превышения driver возвращает SQLTimeoutException и пытается отменить работу. Это ещё не доказательство, что сервер базы уже остановился.
Для полностью зависшей сети действует аварийный предел. В терминах JDBC network timeout помечает connection closed — проще говоря, Java закрывает соединение. Oracle рекомендует делать этот срок длиннее обычного времени на запрос.
PostgreSQL разделяет долгий запрос, ожидание занятой записи и забытую открытую транзакцию. Им нужны разные пределы.
Мой порядок:
— срок всей пользовательской операции;
— меньший срок для SQL;
— ещё меньший — для ожидания блокировки;
— аварийное закрытие сети последним.
После ошибки проверяю, что запрос остановлен, а соединение вернулось в пул.
#Java #JDBC #PostgreSQL #reliability
Совместимая схема. Replay всё равно может разнести прод
Registry-check зелёный — и все счастливы. Жаль, что он не доказывает, сможет ли новый код безопасно перечитать старую историю.
Avro 1.12 задаёт для single-object encoding ровно 10 байт префикса: 2 байта marker C3 01 и 8 байт CRC-64 fingerprint. Fingerprint указывает на writer schema, но не заменяет её архив.
В конфигурации Apache Kafka 4.3 broker defaults — retention 168 часов и segment 1 GiB. Это не гарантия topic: overrides и compaction могут оставить меньше истории.
Replay безопасен, когда writer schemas сохранены, reader проверен на историческом корпусе, известны earliest offsets, dry run изолирован, а downstream идемпотентен.
Совместимость схемы — один чекбокс, а не бронежилет. Первый полный replay обычно объясняет это без лишней деликатности.
#Java #Kafka #Avro #архитектура
Registry-check зелёный — и все счастливы. Жаль, что он не доказывает, сможет ли новый код безопасно перечитать старую историю.
Avro 1.12 задаёт для single-object encoding ровно 10 байт префикса: 2 байта marker C3 01 и 8 байт CRC-64 fingerprint. Fingerprint указывает на writer schema, но не заменяет её архив.
В конфигурации Apache Kafka 4.3 broker defaults — retention 168 часов и segment 1 GiB. Это не гарантия topic: overrides и compaction могут оставить меньше истории.
Replay безопасен, когда writer schemas сохранены, reader проверен на историческом корпусе, известны earliest offsets, dry run изолирован, а downstream идемпотентен.
Совместимость схемы — один чекбокс, а не бронежилет. Первый полный replay обычно объясняет это без лишней деликатности.
#Java #Kafka #Avro #архитектура
Один предохранитель не спасает сервис от перегрузки
Resilience4j CircuitBreaker замечает частые ошибки и медленные ответы. Если сервис явно болеет, новые обращения временно прекращаются.
Но в нормальном режиме все 20 вызовов всё равно могут уйти одновременно. Для защиты нужны разные ограничения:
— Bulkhead ограничивает число одновременных запросов;
— RateLimiter ограничивает скорость потока;
— TimeLimiter ограничивает время ожидания;
— Circuit Breaker решает, когда перестать доверять больному сервису.
Они дополняют друг друга. Наличие одного Circuit Breaker ещё не защищает от каскадного сбоя. Нагрузочный тест должен показать, что очереди и соединения не переполняются, повторы не усиливают аварию, а зависший запрос действительно останавливается.
#architecture #resilience #Java #systemdesign
Resilience4j CircuitBreaker замечает частые ошибки и медленные ответы. Если сервис явно болеет, новые обращения временно прекращаются.
Но в нормальном режиме все 20 вызовов всё равно могут уйти одновременно. Для защиты нужны разные ограничения:
— Bulkhead ограничивает число одновременных запросов;
— RateLimiter ограничивает скорость потока;
— TimeLimiter ограничивает время ожидания;
— Circuit Breaker решает, когда перестать доверять больному сервису.
Они дополняют друг друга. Наличие одного Circuit Breaker ещё не защищает от каскадного сбоя. Нагрузочный тест должен показать, что очереди и соединения не переполняются, повторы не усиливают аварию, а зависший запрос действительно останавливается.
#architecture #resilience #Java #systemdesign
JDK 27 предложит гибридный TLS без правок в коде
OpenJDK JEP 527 добавляет в TLS 1.3 гибридный обмен ключами. Схема X25519MLKEM768 соединяет классический X25519 и постквантовый ML-KEM-768: защита сохраняется, пока не сломаны обе части.
JDK ставит эту группу первой. Обычный код на javax.net.ssl получит её автоматически, если сервер тоже поддерживает группу и приложение не закрепило свой список. Традиционный x25519 остаётся запасным вариантом.
Что проверить на стенде:
— какая группа реально согласована;
— проходят ли рукопожатия через прокси и средства проверки трафика;
— как изменились размер и время рукопожатия;
— не задан ли старый jdk.tls.namedGroups.
Спецификации гибридных групп ещё могут измениться до RFC. Поэтому новый default полезен, но совместимость всей TLS-цепочки всё равно доказывает тест.
#Java #JDK27 #TLS #security #новости
OpenJDK JEP 527 добавляет в TLS 1.3 гибридный обмен ключами. Схема X25519MLKEM768 соединяет классический X25519 и постквантовый ML-KEM-768: защита сохраняется, пока не сломаны обе части.
JDK ставит эту группу первой. Обычный код на javax.net.ssl получит её автоматически, если сервер тоже поддерживает группу и приложение не закрепило свой список. Традиционный x25519 остаётся запасным вариантом.
Что проверить на стенде:
— какая группа реально согласована;
— проходят ли рукопожатия через прокси и средства проверки трафика;
— как изменились размер и время рукопожатия;
— не задан ли старый jdk.tls.namedGroups.
Спецификации гибридных групп ещё могут измениться до RFC. Поэтому новый default полезен, но совместимость всей TLS-цепочки всё равно доказывает тест.
#Java #JDK27 #TLS #security #новости
Virtual Threads не размножают CPU и коннекты. Сюрприз
Virtual Threads масштабируют blocking I/O без отдельного дорогого platform thread на каждую задачу. Они удешевляют ожидание, но не создают CPU, соединения с БД или capacity downstream — физика опять испортила презентацию.
OpenJDK в JEP 444 показывает 10 000 одновременных задач как демонстрацию и прямо советует не пулить virtual threads. JEP 491 в JDK 24 устранил почти всё synchronized-pinning; JFR сохраняет диагностику редких native/class-init случаев.
Статусы OpenJDK: Virtual Threads final в JDK 21, Scoped Values final в 25, Structured Concurrency — 6-й preview в 26 и 7-й в 27.
100 000 запросов к pool из 100 DB connections дают максимум 100 активных операций и до 99 900 ожидающих. Ограничивать нужно scarce resource, а не virtual threads.
Забивать очередь дешёвыми потоками — всё ещё херовая архитектура, просто теперь она дешевле ждёт.
#Java #JVM #VirtualThreads
Virtual Threads масштабируют blocking I/O без отдельного дорогого platform thread на каждую задачу. Они удешевляют ожидание, но не создают CPU, соединения с БД или capacity downstream — физика опять испортила презентацию.
OpenJDK в JEP 444 показывает 10 000 одновременных задач как демонстрацию и прямо советует не пулить virtual threads. JEP 491 в JDK 24 устранил почти всё synchronized-pinning; JFR сохраняет диагностику редких native/class-init случаев.
Статусы OpenJDK: Virtual Threads final в JDK 21, Scoped Values final в 25, Structured Concurrency — 6-й preview в 26 и 7-й в 27.
100 000 запросов к pool из 100 DB connections дают максимум 100 активных операций и до 99 900 ожидающих. Ограничивать нужно scarce resource, а не virtual threads.
Забивать очередь дешёвыми потоками — всё ещё херовая архитектура, просто теперь она дешевле ждёт.
#Java #JVM #VirtualThreads
Три коробки observability — ещё не наблюдаемость
Можно купить backend для метрик, логов и traces, а потом всё равно узнавать о падении от пользователя. Коробки есть, понимания системы — как повезёт.
Для 30-дневного SLO 99,9% бюджет равен 43 мин 12 с. Google SRE Workbook предлагает стартовые multi-window alerts:
— page: 14,4×, окна 1 h / 5 min, расход 2%;
— page: 6×, 6 h / 30 min, расход 5%;
— ticket: 1×, 3 d / 6 h, расход 10%.
Метрика показывает форму ущерба, trace — путь, structured log — детали. OpenTelemetry задаёт semantic attributes вроде service.name; trace_id приходит из trace context, это другой слой.
Page должен отвечать на пользовательский симптом или быстрый burn rate, а не на внутреннюю метрику, которую просто удобно повесить на дежурного.
Observability — это способность ответить «что сломалось и почему», а не три дорогих логотипа в архитектурной схеме.
#Java #SRE #observability
Можно купить backend для метрик, логов и traces, а потом всё равно узнавать о падении от пользователя. Коробки есть, понимания системы — как повезёт.
Для 30-дневного SLO 99,9% бюджет равен 43 мин 12 с. Google SRE Workbook предлагает стартовые multi-window alerts:
— page: 14,4×, окна 1 h / 5 min, расход 2%;
— page: 6×, 6 h / 30 min, расход 5%;
— ticket: 1×, 3 d / 6 h, расход 10%.
Метрика показывает форму ущерба, trace — путь, structured log — детали. OpenTelemetry задаёт semantic attributes вроде service.name; trace_id приходит из trace context, это другой слой.
Page должен отвечать на пользовательский симптом или быстрый burn rate, а не на внутреннюю метрику, которую просто удобно повесить на дежурного.
Observability — это способность ответить «что сломалось и почему», а не три дорогих логотипа в архитектурной схеме.
#Java #SRE #observability
👍1