Spring АйО
10.3K subscribers
424 photos
291 videos
550 links
Русскоязычное сообщество Spring-разработчиков.

Habr: bit.ly/433IK46
YouTube: bit.ly/4h3Ci0x
VK: bit.ly/4hF0OG8
Rutube: bit.ly/4b4UeX6
Яндекс Музыка: bit.ly/3EIizWy

Чат для общения: @spring_aio_chat
По вопросам сотрудничества: @befayer
Download Telegram
🥳🥳🥳🥳🥳
Please open Telegram to view this post
VIEW IN TELEGRAM
11👍89🔥69166🤩4
Media is too big
VIEW IN TELEGRAM
🍃 Go vs Java, Redis как кэш, Istio vs Nginx | Spring АйО Подкаст №49

😉 СМОТРЕТЬ НА YOUTUBE
😄 СМОТРЕТЬ В VK ВИДЕО
🥰 СМОТРЕТЬ НА RUTUBE
🗯 СЛУШАТЬ НА ЯНДЕКС.МУЗЫКЕ
🤩 СЛУШАТЬ НА SPOTIFY
🤩 СЛУШАТЬ НА APPLE PODCASTS

💬 Аудио версию подкаста можно найти в комментариях
Please open Telegram to view this post
VIEW IN TELEGRAM
19👍14🔥8
👩‍💻 Почему ваш Docker-контейнер взломают завтра (и как этого избежать)

«Контейнер скомпрометирован». С этих слов начался трёхчасовой ночной кошмар с утечкой данных и полным отчётом об инциденте. Всё из-за банального запуска контейнера от root с лишними правами.

В новом переводе от команды Spring АйО — 11 конкретных шагов, которые помогут вам избежать катастрофы: от запуска от непривилегированного пользователя до минимальных образов, сканирования уязвимостей, изоляции сетей и настройки профилей безопасности.

Если вы разворачиваете контейнеры в продакшене — это руководство должно стать вашей чеклист-основой. Ошибка может стоить очень дорого.

📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/992696/
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2510👍5🤯1
🚨 Роняем базу из-за кеша без смс и регистрации

Горячий ключ кэша истёк — и за 2 секунды база получила 10 000 одновременных запросов. Попадания в кеш были ~ 95%, пятничных релизов не было, плохих запросов в БД никто не отправлял. Просто одновременно закончился TTL на тысячах инстансов. Они одномоментно не нашли данных в кеше и полезли за ними в БД

Что помогает, если ключи реально «горячие» (то есть, какие-то пары ключ/значение в кеше запрашиваются крайне часто).

Stale-while-revalidate: если запись просрочена, но есть, то отдаём её сразу, а обновление запускаем параллельно.

Probabilistic early expiration: часть запросов с небольшой вероятностью инициирует обновление до дедлайна, чтобы обновления распределились по времени.

Mutex / single-flight: при промахе один запрос обновляет кэш под блокировкой, остальные ждут немного или получают stale; в базу уходит один запрос вместо тысячи.

Комбинация этих подходов в реальных системах снижает нагрузку на БД во время истечения срока на 50–90% и сглаживает пики задержек.

📚 Полный текст по ссылке: https://habr.com/ru/companies/spring_aio/articles/993140/
Please open Telegram to view this post
VIEW IN TELEGRAM
👍27🔥148
📊 Экосистема Spring в 2024/2025 годах

Друзья, каждый год мы проводим одно и то же исследование: смотрим, как меняется популярность ключевых зависимостей вокруг Spring по публичным проектам на GitHub (через dependency search). Это не истина в последней инстанции, но хорошая лакмусовая бумага: можно быстро понять, куда двигается массовая практика.

Сразу оговорка по методике: мы считаем упоминания зависимостей, а не уникальные репозитории. Один проект может «голосовать» сразу за 10 библиотек, и это нормально. Поэтому смотрите не на абсолютные числа и даже не на темпы роста как таковые, а на соотношения темпов роста "конкурирующих" технологий.Большая часть проектов на GitHub - это простые "pet projects", которые не говорят об использовании конкретных технологий в production, но говорят о том, какие технологии люди знают и в целом изучают.

🛑1. Использование ключевых Spring Boot зависимостей растёт:

spring-boot-starter-web +11%,
spring-boot-starter-graphql +34%,
spring-boot-starter-webflux +48%.

Неожиданный относительный рост spring-boot-starter-webflux при том, что ряд reactive проектов Spring Framework сансетит.


🛑2. Data-слой растет во всех направлениях:

spring-data-cassandra +3%,
spring-data-jpa +24%,
spring-data-jdbc +29%,
spring-data-redis +42%,
spring-data-mongodb +49%,


И непосредственно драйверы

org.postgresql +19%,
com.oracle.database.jdbc +80%,
mysql-connector-j +48%.


Здесь важна структура роста:

🛑JPA растет — Hibernate/JPA никуда не делись и остаются стандартом для большинства пользователей кейсов.

🛑Тем не менее, параллельно уверенно растет Spring Data JDBC. То есть, разработчики всё чаще ищут замену тяжеловесному Hibernate в мире ORM.


🛑3. Микросервисная инфраструктура ускорилась:

spring-cloud-consul-config
spring-cloud-config-server


Люди гораздо чаще используют Spring Cloud Config, чем интеграцию с Hashicorp Vault. Вероятно, это связано с тем, что Spring Cloud Config является проверенным временем решением под Apache License 2.0, где Hashicorp Vault является более редким решением, которое, к тому же, из-за политики лицензирования имеет ряд ограничений при использования в Production.


🛑4. По API-докам видно, кто живет по инерции:

Springfox почти стоит (+5%),
Springdoc растет, но умеренно (+13%).

Springfox не исчез, но выглядит как технология поддержки существующих кодовых баз. Новые проекты все чаще выбирают OpenAPI-стек, просто без резких скачков от года к году.


🛑5. Maven vs Gradle: без революции

По долям картина стабильная:

Maven ~81%, Gradle ~19% и в 2024, и в 2025. Большого перетока не видно. Скорее, Gradle уже давно стал значимой частью ландшафта, и так и остается.


🛑6. MapStruct vs ModelMapper:

Если вынести маппинг DTO/Entity в отдельный мини-срез, получается любопытная картина:

🛑MapStruct — больше по базе и дает больший прирост в количестве: 67 700 → 102 000 (Δ +34 300, +51%)

🛑ModelMapper — растет быстрее по темпу, но стартует с меньшей базы: 47 652 → 78 520 (Δ +30 868, +65%)

Вывод простой: MapStruct остается “дефолтом” по массовому использованию, а ModelMapper выглядит как инструмент, который уверенно догоняет по темпам роста.


А что будет в 2026? Обсудим в комментариях.

* Все данные получены анализом зависимостей, используемых в проектах на GitHub (dependency search)."
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍36🔥108
Forwarded from TechMeetup
TechMeetup #11: Spring АйО x МТС Банк

🗒 Spring АйО собрали несколько интересных докладов, МТС Банк опять ждет в гости

Всё как всегда — четыре доклада, нетворкинг, афтепати и активности от партнера, но в новом формате со спикерами от русскоязычного сообщества Spring.

🗓 Когда: 26 февраля 2026, с 19:00 до 22:30 GMT+03:00 (онлайн и офлайн);
📍 Где (офлайн): Москва, м. Технопарк. Проспект Андропова 18, корпус 1. (Здание с вывеской МТС Банк, Медиарум);

👍 Участие: бесплатно
🎉 Нетворкинг: бесценно

🔗 Подробнее о программе на странице мероприятия

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

Ждем именно тебя 🫵

🎁 Бонусы: еда и напитки в перерыве, маленький праздник среди недели. А вместе с нетворкингом и активностями от МТС Банка - время, проведенное с пользой и удовольствием.

Регистрируйся, места на офлайн часть ограничены

Spring АйО | МТС Банк

TechMeetup/Java | JVM | CFP: Подать доклад | Общалка и вопросы | Записи
Please open Telegram to view this post
VIEW IN TELEGRAM
16👍12🔥8👎2🤔1
Forwarded from OpenIDE
Современный senior Spring-разработчик просто обязан разбираться в Kubernetes!

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

В новом докладе Илья Кучмин рассказал, что необходимо знать, какие есть подводные камни, на что обратить внимание и как применять инструменты деплоя в Kubernetes.

😉 СМОТРЕТЬ НА YOUTUBE
😄 СМОТРЕТЬ В VK ВИДЕО
Please open Telegram to view this post
VIEW IN TELEGRAM
👍39🔥156👎2
Media is too big
VIEW IN TELEGRAM
🍃 Экосистема Spring, секьюрность Docker, как не уронить базу из-за кеша | Spring АйО Подкаст №50

😉 СМОТРЕТЬ НА YOUTUBE
😄 СМОТРЕТЬ В VK ВИДЕО
🥰 СМОТРЕТЬ НА RUTUBE
🗯 СЛУШАТЬ НА ЯНДЕКС.МУЗЫКЕ
🤩 СЛУШАТЬ НА SPOTIFY
🤩 СЛУШАТЬ НА APPLE PODCASTS

💬 Аудио версию подкаста можно найти в комментариях
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19👍97👎1
Forwarded from Amplicode
Media is too big
VIEW IN TELEGRAM
Ctrl+C → Ctrl+V на стероидах

Автоимпорт при копировании кода — штука настолько приятная и удобная, что без неё уже невозможно представить работу в IDE.

Мы пошли дальше и вслед за умным импортом во время набора кода сделали автоматическую инжекцию бинов при копировании кода!

Теперь при копировании кода Amplicode автоматически добавляет нужную инжекцию бинов. С учётом контекста, @Primary, @Qualifier, дженериков, @Bean-методов, Java и Kotlin — без ручной возни после вставки.

Доступно всем пользователям Amplicode, без подписки.
👍34🤯13🔥952👎1🤔1
🍃 Стань частью Spring АйО × JPoint 😀

Друзья, хотим напомнить, что в этом году Spring АйО представляет собственный трек на конференции JPoint.

Помимо самого выступления хотим напомнить о дополнительных фичах участия:

– возможность пообщаться с легендами мира IT
– получить ачивку "я спикер вообще-то"
– побывать на стендах ведущих компаний РФ
– бесплатно съездить и пожить в столице
– послушать другие доклады
– оторваться на афтерпати
– попросить больше з/п у руководства (тут гарантий не дадим, только инструкцию)


После первого поста трек почти укомплектован. Но осталась пара мест. Если сомневаешься - эксперты не кусаются и покажут, как лучше, где поправить, а где, наоборот, вышло уже супер круто.

📩 Заявку на участие можно оставить тут: https://spring-aio.ru/2026
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥20👍86🤩1
🔥 HotSpot AOT-кэш: стартуем быстрее, греемся меньше

В HotSpot появился AOT-кэш, который сохраняет уже разобранные, загруженные и слинкованные классы приложения. Это снижает warm-up time и ускоряет выход на пик после старта.

JDK 24:

Трёхшаговый процесс train+assemble+run (JEP 483).

Training:

-XX:AOTMode=record -XX:AOTConfiguration=app.aotconf

Создает конфигурацию, необходимую для дальнейшего построения кеша.

Assembly:

-XX:AOTMode=create ... -XX:AOTCache=app.aot собирает кэш.

Run:

-XX:AOTCache=app.aot использует его при запуске.


JDK 25:

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

Также появился упрощённый workflow в 2 шага через -XX:AOTCacheOutput=app.aot (JEP 514), но он может требовать 2x памяти: при -Xms2g -Xmx2g окружению нужно около 4 ГБ, потому что сборка кэша запускается с отдельной кучей того же размера.

Чтобы кэш применился, окружения должны совпадать: тот же JDK/OS/архитектура, classpath только из JAR без wildcard/каталогов, prod classpath - надмножество training.

Проверка: -XX:AOTMode=on.


JDK 26:

С JDK 26 сняли ограничение по ZGC (JEP 516). Для диагностики: -Xlog:aot,class+path=info. Кэш нужно пересоздавать при любой пересборке приложения или обновлении библиотек/JDK, иначе возможны краши и странное поведение.


📚 Полный текст по ссылке: https://habr.com/ru/companies/spring_aio/articles/995398/
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1576👍4
👩‍💻 Программирование, ориентированное на данные, для Java: за пределами record-классов

Record-классы удобны, пока класс = «состояние, всё состояние и ничего кроме». Любое отклонение (API канонического конутруктора не равно внутреннему представлению, нужно наследование) ломает «автогенерацию» и паттерн-деструктурирование (destructuring).

В новом переводе от команды Spring АйО статьи Brian`а Goetz`а, архитектора Java Language, предлагается следующий шаг в направлении data-oriented programming in Java: классы-носители и интерфейсы-носители (они же Carrier classes & interfaces). Концептуально, carrier классы родились из record-ов путем ослабления части их ограничений.

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

Друзья, помните, пожалуйста, что данная статья по сути является суммированием обсуждения Carrier классов из JDK Project Amber Mailing List. Я это к тому, что пока непонятно, в какой версии языка carrier классы появятся, и появятся ли они в том виде, в котором представлены в статье. Статья больше пища для размышления


📚 Полный текст по ссылке: https://habr.com/ru/companies/spring_aio/articles/995824/
Please open Telegram to view this post
VIEW IN TELEGRAM
👍18🔥1082
⚠️ Java продолжает готовиться к удалению finalize()

В рамках JDK 27 у ThreadPoolExecutor-а, очень популярного API в Java, будет удалён метод finalize(). Несмотря на то, что в силу dynamic dispatch вызов метода finalize() всё равно будет транслирован в Object, данное изменение не source level compatible.

А все потому, что у Object.finalize() сигнатура содержит throws Throwable, в то время как ThreadPoolExecutor.finalize() — нет. Пока метод был в ThreadPoolExecutor, компилятору было ок. Как только его удалят, вызов super.finalize() начнет резолвиться в Object.finalize(), и тогда прилетит “unreported exception Throwable”.

Комментарий от Михаила Поливаха:
Вот это кстати довольно редкий пример того, что имзенение может быть binary level compatible, но не source level compatible.


Например:


class MyPool extends ThreadPoolExecutor {
@Override
protected void finalize() {
super.finalize(); // JDK 27: теперь это Object.finalize() throws Throwable
}
}


Как избежать?

* поискать и удалить любые finalize() / super.finalize() (и вообще любые авто-cleanup через финализацию)
* управлять жизненным циклом executor’ов явно: shutdown()/awaitTermination() или просто close() в try-with-resources (да, ExecutorServiceAutoCloseable)

Spring АйО рекомендует не использовать finalize() в целом, но если подобного рода хук нужен, то лучше использовать Java Cleaner API. С его помощью нельзя "случайно" воскресить объект, сломать integrity объекта или т.п.

Ждем JDK 27 🫠
👍28🔥96