Для JetBrains IDE вообще есть нормальный AI без проблем в РФ?

Периодически в @spring_aio_chat и на Хабре прилетают вопросы про то, какие сейчас есть варианты использования ИИ внутри IDE.

Один из вариантов – Kodacode.

Работает:
— в OpenIDE и JetBrains IDE
— в VS Code
— и даже в CLI

Что кажется наиболее полезным:
— агентный режим: без него от ИИ-помощника смысла не так много
— доступ к разным моделям: GLM, Gemini, DeepSeek, и другие
— работает без танцев с VPN и оплатами: у многих это сейчас главный стоп-фактор для AI-инструментов
— есть бесплатная модель: хватает для повседневных задач

📚 Подробнее про Koda для JetBrains IDE читайте на Хабр: https://habr.com/ru/companies/koda/articles/986976/

👩‍💻 JEP 524 в JDK 26 — второй preview PEM API.

Наконец-то работа с PEM в Java становится похожа на API, а не на набор ручного парсинга, Base64 и странных телодвижений.

Справка: PEM или Privacy-Enhanced Mail - это текстовый контейнер для криптографических данных. Проще говоря – это способ хранить или передавать ключ, сертификат или другой crypto-объект не в бинарном виде, а в текстовом.

Раньше с PEM работали так:

String pem = "-----BEGIN PUBLIC KEY-----\n"
        + Base64.getMimeEncoder(64, "\n".getBytes())
                .encodeToString(publicKey.getEncoded())
        + "\n-----END PUBLIC KEY-----";

А в обратную сторону, но уже с ручной нормализацией PEM, Base64-декодированием и KeyFactory:

String normalized = pem
        .replace("-----BEGIN PUBLIC KEY-----", "")
        .replace("-----END PUBLIC KEY-----", "")
        .replaceAll("\\s", "");

byte[] der = Base64.getDecoder().decode(normalized);

PublicKey key = KeyFactory.getInstance("EC")
        .generatePublic(new X509EncodedKeySpec(der));

По факту PEM в Java долгое время был не отдельным API, а набором низкоуровневых шагов, которые разработчик собирал руками.

А теперь это выглядит так:

var encoder = PEMEncoder.of();
String pem = encoder.encodeToString(keyPair);

var decoder = PEMDecoder.of();
KeyPair decoded = decoder.decode(pem, KeyPair.class);

То есть ключевую пару можно закодировать в PEM и декодировать обратно буквально в несколько строк.

Во втором preview:
— PEMRecord переименовали в PEM
— добавили decode()
— расширили поддержку KeyPair и PKCS8EncodedKeySpec
— упростили шифрование через EncryptedPrivateKeyInfo

А так, как все это дело еще в preview, не забываем использовать --enable-preview.

❓ Минус еще один кусок криптографической копипасты из Java-кода. PEM в Java постепенно перестает быть унылым?

#видеозаписи

Открываем новую видеозапись доклада:
Михаил Поливаха — Spring AOT: кодогенерация на стероидах

😉 YouTube | 📺 VK Видео

🗑️ Изменения в G1/Parallel/Serial GC в JDK 26

JDK 26 выходит уже совсем скоро. Тем временем в GC закрыли около 380 задач (почти в 2 раза больше, чем в прошлом релизе), но в этот раз акцент сместился с больших фич в пользу практичных доработок.

Главное для всех сборщиков: нормальный учет CPU GC. Теперь считают не только stop-the-world паузы, но и конкурентную работу и дедупликацию строк. Можно посмотреть через лог cpu=info при завершении VM, обновили Hsperf-счетчики, есть доступ из кода. Плюс новый JFR-ивент с деталями по string dedup.

JEP 516: Aot Cache стал независим от выбранного GC и опций VM. Включение через опцию -XX:+AOTStreamableObjects.

G1 получил самые заметные улучшения: JEP 522 уменьшает синхронизацию между GC и приложением (цель - увеличить throughput). Еще: целевое использование CPU G1 по умолчанию снижено с 8% до 4%, добавили важнейший флаг UseGCOverheadLimit.

Комментарий от Михаила Поливаха:

Важно и то, что HotSpot GC команда в Oracle смотрит в сторону Automatic Heap Sizing. На эту темы было много шума на Redit и не зря. Поговорим об этом на подкасте.

📎 Подробнее в статье: https://habr.com/ru/companies/spring_aio/articles/1010904/

👩‍💻 Привет, Java 26!

Встречаем 26 версию нашего любимого языка программирования.

Что самое заметное:

☑️ HTTP/3 в HttpClient (JEP-517)
Теперь java.net.http.HttpClient умеет HTTP/3. Для client-side кода это хороший апгрейд: меньше магии, ближе к современному вебу из коробки.

☑️ G1 стал быстрее по throughput (JEP-522)
В Java 26 уменьшили синхронизацию между application threads и GC threads. Для тех, кто сидит на G1 по умолчанию, это может дать вполне практичный прирост без смены GC и без шаманства с флагами.

☑️ Structured Concurrency все еще с нами (JEP-525)
Уже шестой preview, но направление давно понятно: многопоточность в Java все сильнее движется к более внятной модели управления связанными задачами, отменой и ошибками. Для сервисного кода — очень правильный вектор.

☑️ Pattern Matching расширили на примитивы (JEP-530)
instanceof, switch, patterns — теперь и для примитивных типов. Пока preview, но курс очевиден: язык становится ровнее и выразительнее.

☑️ Vector API продолжает дозревать (JEP-529)
Уже 11-й incubator. Для high-performance сценариев, аналитики и местами AI/inference должно быть полезным.

☑️ Leyden-путь продолжается (JEP-516)
AOT object caching теперь работает с любым GC, включая ZGC. То есть разговор про быстрый startup/warmup Java-приложений становится еще менее "на словах".

☑️ final начинают защищать всерьез (JEP-500)
Добавляются предупреждения на deep reflection, который мутирует final-поля. Java продолжает двигаться к integrity by default. Если у вас есть старые хаки через reflection, то самое время проверить, не пора ли их вычищать.

☑️ Applet API удалили окончательно (JEP-504)
Да, в 2026 это уже скорее символический жест. Но хороший, так платформа продолжает избавляться от давно мертвого наследия.

А ещё:

🔘Process теперь AutoCloseable
🔘появился UUIDv7 через UUID.ofEpochMillis(...)
🔘Javadoc получил dark theme
🔘Thread.stop() удален окончательно
🔘виртуальные потоки стали аккуратнее вести себя в одном неприятном сценарии с class initialization

Итог

Пожалуй, нас не порадовали “кричащими” фичами уровня смены эпохи, но есть много сильных улучшений в том, что реально влияет на повседневную разработку: сеть, GC, concurrency, безопасность, startup и чистка платформы от старого балласта.

📎Полный список изменений тут: https://jdk.java.net/26/release-notes

❓Кто уже успел посмотреть JDK 26 — что зацепило больше всего?

🌎 О размерах пула соединений

Есть такой момент, что большой пул часто ухудшает отклик: БД упирается в ограниченные ресурсы (CPU, диск, сеть), начинается лишняя конкуренция и накладные расходы, latency растет.

Действительно, ребята из Oracle в своей демке обычным уменьшением пула снизили время ответа примерно со 100 мс до 2 мс.

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

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

📎 Подробнее в статье на Хабр: https://habr.com/ru/companies/spring_aio/articles/1011770/

🤩 Netflix: практическое применение Vector API, которое спасло CPU

Иногда одна незаметная фича может сжигать гигантский объём ресурсов. В Netflix именно так и вышло: скоринг серендипности в Ranker оказался дорогой горячей точкой, а попытка слегка его ускорить в итоге привела к большой инженерной перестройке — от батчинга до SIMD через JDK Vector API.

Получился отличный разбор того, как SIMD AVX инструкции на практике позволили снизить потребление CPU.

🤓 Я сам не знал, поэтому: скоринг серендипности — это попытка алгоритма измерить приятную неожиданность рекомендации.

📎 Подробнее в статье на Хабр: https://habr.com/ru/companies/spring_aio/articles/1012732/

👻 Spring Data. На пути к более строгой типизации

В Spring Data динамические фильтры и сортировки часто строят по строкам: Sort.by("firstName"), where("address.country").is(...). В целом это довольно удобно и поддерживается большинством модулей Spring Data.

Однако потом возникают проблемы в поддержке софта. Опечатки и переименования свойств при рефакторинге спокойно собираются и ломаются только в рантайме. Да и IDE тоже почти не помогает, потому что строка для нее просто текст.

Альтернатива в Java давно есть: метамодели (Querydsl, JPA Metamodel Generator) и подходы от схемы БД (jOOQ). Они дают проверку на этапе компиляции, но обычно требуют annotation processing/плагины, влекут пересборки и добавляют зависимости и нюансы в IDE.

Так вот, в Spring Data 2026.0.0-M1 появился третий вариант: типобезопасные ссылки на свойства без генерации. Вместо строк можно передавать ссылки на методы/свойства: Sort.by(Person::getFirstName, Person::getLastName), для вложенных путей - PropertyPath.of(Person::getAddress).then(Address::getCountry). Путь валидируется типами, а ссылки интроспектируются один раз и кэшируются. Для Kotlin всё ещё лучше.

📎 Полный текст — по ссылке: https://habr.com/ru/companies/spring_aio/articles/1014920/

❓ DPoP: что это такое, как работает и почему Bearer-токенов недостаточно

Утек access token - и работает он у того, кто его нашел. Так устроены Bearer-токены: сервер верит любому, кто предъявил строку из заголовка Authorization.

Отсюда и всем знакомые истории: Codecov (2021) потерял токены из-за Supply Chain Injection в CI/CD, GitHub (2022) потерял OAuth-токены Heroku и Travis CI, в Microsoft (2023) в репозитории оказался слишком «широкий» SAS-токен, открывавший доступ к 38 ТБ данных (тыц, тыц). Во всех случаях токен оказался у посторонних и его просто использовали.

DPoP (RFC 9449) предлагает другой контракт. Токен привязывается к ключу клиента, а каждый запрос сопровождается DPoP proof-JWT, подписанным приватным ключом. Сервер сверяет подпись и отпечаток ключа (cnf.jkt) внутри access token.

Данный механизм является необязательным расширением для OAuth2 и позволяет избежать ситуации, при которой утечка Access Token-а становится фатальной для Backend-а.

📎 Полный текст — по ссылке: https://habr.com/ru/companies/spring_aio/articles/1015544/

⚡️ Евгений Борисов — Spring-потрошитель, 12 лет спустя

Если ты сидишь в этом канале и всё ещё не смотрел легендарный доклад Евгения Борисова "Spring-потрошитель", то у нас для тебя 2 новости:

1. Ты бесконечно много упустил. Та БАЗА, которую Женя выдал в этом докладе, стала фундаментом для целого поколения разработчиков.
2. Теперь наверстать упущенное можно в 10 раз веселее!

Саня, Миша и Гошан записали 2.5-часовой РЕАКТ.

Смотрим, смеёмся и ностальгируем. Приятного повторного просмотра старичкам и первого просмотра всем зумерам.

Надеемся, грядущий JPoint 2026 подарит не меньше легендарных материалов)

😉 СМОТРЕТЬ НА YOUTUBE
😄 СМОТРЕТЬ В VK ВИДЕО
🥰 СМОТРЕТЬ НА RUTUBE

🩷 OpenTelemetry со Spring Boot

В новом переводе от команды Spring АйО смотрим, как подружить современный Spring Boot и OpenTelemetry так, чтобы данные уходили по OTLP в любой совместимый бэкенд.

В экосистеме Spring большая часть телеметрии была завязана на Micrometer Project (Был ещё spring-cloud-sleuth если кто помнит). Но полноценного all-in-one решения для того, чтобы Spring Boot приложение просто начало экспортировать телеметрию по OTLP не было. До Spring Boot 4.

На данный момент для интеграции OTel в Spring Boot приложения есть 3 пути: Java Agent (минимум кода, но чувствителен к версиям и может конфликтовать с другими агентами), сторонний OTel starter (стартер от самих OpenTelemetry, но тянет alpha-зависимости) и новый spring-boot-starter-opentelemetry, доступный в Spring Boot 4.0.

📎Читать тут: https://habr.com/ru/companies/spring_aio/articles/1017016/

⚡️ Spring АйО Академия

— наш центр компетенции по Spring и enterprise-разработке на русском языке.

На базе сообщества Spring АйО мы запускаем программы обучения для Middle/Senior разработчиков — от практикующих экспертов, которые сами пишут production-ready код для высоконагруженных приложений.

Первую программу ведёт Михаил Поливаха — контрибьютор в Spring Data, спикер JPoint, Joker, Devoxx, Spring I/O.

Тема — Продвинутый Hibernate: решение вызовов уровня Enterprise.

Для тех, кто умеет писать запросы, но сталкивался с тем, что ORM в реальных системах ведёт себя не так, как на слайдах.

N+1, OFFSET на больших таблицах, @BatchSize, StatelessSession, Soft Delete, Transactional Outbox, @TenantId и работа с большими объёмами данных.

⭐️ Набор на первый поток будет идти весь апрель, стартуем в мае, сразу после JPoint 2026!

📎 Ознакомиться с программой подробнее и записаться можно тут: https://spring-aio.ru/advanced_hibernate

🔼 Оптимизация запросов в Spring Data JDBC

Spring Data JDBC всегда была «белой вороной» в мире Java ORM. Она проще Hibernate, но эта простота имеет свою цену.

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

Михаил в своей статье разбирает, как выжать максимум из Spring Data JDBC, когда стандартные подходы не справляются.

📎 Читать на Хабре: https://habr.com/ru/companies/spring_aio/articles/1010558/

👩‍💻 Раздувание памяти JDK 17 в контейнерах: разбор инцидента

Апгрейд микросервисов с JDK 8 на JDK 17 прошел dev и QA спокойно, но в проде через 2-3 часа все начало падать. Утилизация памяти выросла в 4 раза, контейнеры стали ловить OOMKill и перезапускаться, Uptime SLA просел, массовый инцидент.

Раньше JVM использовала около 50% памяти контейнера и обслуживала ~400 потоков. После релиза стало 95-100% и 1600+ соответственно.

При этом heap выглядел нормально, около Xmx, а раздувалась нативная память: ~800 MB -> 3,4-3,6 GB. Виноваты несколько эффектов, которые в контейнерах усиливаются: JVM начала создавать намного больше потоков, OS стала выделять JVM гораздо больше, а дефолтный GC в JDK 17 добавил накладные расходы.

Всё это из-за простого бага в JDK, который при миграции утащил за собой весь production.

📎 Читать на Хабре: https://habr.com/ru/companies/spring_aio/articles/1019086/

🔥 Профилирование? Не, не слышал

Друзья, следующий подкаст пройдет не как обычно, а с очень уважаемыми IT индустрией людьми - Владимиром Плизга и Алексеем Рагозиным - настоящими гуру JVM performance.

У нас, конечно же, есть, что обсудить.

Например:
🔘Нужны ли профайлеры в 2к26?
🔘Зачем вообще запрофилировать?
🔘Поможет ли ИИ в анализе перформанса?

❓Но мы ждем и ваши вопросы в комментариях под постом. Самые интересные обсудим на подкасте!

❌ Почему merge в Hibernate почти всегда лишний (и чем его заменить)

Чаще всего merge в Hibernate – это лишний SELECT. И это не про сохранение, а про перенос состояния detached-объекта в текущий Persistence Context.

Эту проблему и пути её решения отдельно обсуждали на докладе в рамках Joker Фёдор и Илья.

Встречается это в типичном флоу: findById -> setX -> save.

Внутри @Transactional загруженная сущность уже managed, а UPDATE и так уйдет в момент flush. А вот save в Spring Data JPA нередко уходит в merge и может добавить лишние чтение или копирование.

Отдельная боль - CascadeType.MERGE (или ALL): merge проходит по графу связей, растут накладные расходы и потенциальные SQL.
Не отходя от кассы 🤓

Конечно же, про подобные и более сдожные темы (@BatchSize, пагинация без OFFSET, StatelessSession/Bulk API, Soft Delete, multi-tenancy, outbox и т.д.) у нас есть собственный лекториум, где Михаил все расскажет и покажет.

📎 Читать на Хабре: https://habr.com/ru/companies/spring_aio/articles/1020426/