🔥 ORM снова в огне: почему “Вьетнам индустрии” никуда не делся — и при чём тут Spring Data JDBC
Во время подготовки к Spring Data JDBC Event, эксперт нашего сообщества, Михаил Поливаха, вновь поднял тему, которая болит у индустрии уже больше двух десятилетий. Поводом стала знаменитая статья Джеффа Отвуда (основанная на мыслях Теда Ньюарда) — та самая, где прозвучала фраза
И что самое интересное: в 2025 году она звучит не менее актуально, чем в 2004-м.
Корневая проблема всё та же: объектная модель и реляционная модель — два мира, которые не хотят мириться друг с другом. ORM обещает стать «мостом», но чаще оказывается болотом компромиссов, где всё работает… пока не перестаёт.
В финале Джефф говорит жёстко, но честно: уберите O или уберите R из ORM — и проблема исчезнет.
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/972316/
Во время подготовки к Spring Data JDBC Event, эксперт нашего сообщества, Михаил Поливаха, вновь поднял тему, которая болит у индустрии уже больше двух десятилетий. Поводом стала знаменитая статья Джеффа Отвуда (основанная на мыслях Теда Ньюарда) — та самая, где прозвучала фраза
«ORM — это Вьетнам нашей индустрии»
И что самое интересное: в 2025 году она звучит не менее актуально, чем в 2004-м.
Корневая проблема всё та же: объектная модель и реляционная модель — два мира, которые не хотят мириться друг с другом. ORM обещает стать «мостом», но чаще оказывается болотом компромиссов, где всё работает… пока не перестаёт.
Джефф перечислил 6 путей, которыми индустрия пыталась сбежать от этого несоответствия:
1. Выбросить объекты. Забить на rich-domain подход и возвращать проекции/tuple’ы. Нет объектов ⇒ нет mismatch’а. Практично, как бы цинично это ни звучало.
2. Перейти к "объектным" хранилищам. OODBMS вроде db4o пытались хранить объекты как есть. Идея жила недолго, но как попытка — эпохальная.
3. Писать маппинг руками. JDBC/JOOQ и полный контроль. Иногда это даже предпочтительнее: больно, но честно.
4. Принять ограничения ORM. Hibernate-путь: 70–80% задач закрываем ORM, остальное — raw SQL. Звучит разумно, если не забывать про кэш и согласованность.
5. Встроить реляционность в язык. LINQ, Scala, F#. Красиво, но массовым это так и не стало.
6. Сделать сами объекты реляционными. RowSet/DataSet-подходы. Интересная идея, но нишевая.
В финале Джефф говорит жёстко, но честно: уберите O или уберите R из ORM — и проблема исчезнет.
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/972316/
🔥28👍13🤯6🤔4😁3❤2⚡1
⚡️ JetBrains задеприкейтили K1: начиная с IntelliJ IDEA 2025.3 основным и единственным актуальным режимом становится K2
K2 — это полностью переработанный компилятор Kotlin, построенный на новой архитектуре. Он избавляет IDE от привязки к внутренностям старого компилятора и обеспечивает поддержку будущих языковых фич, стабильность и масштабируемость.
Адаптация почти завершена: среди пользователей версии 2025.2 K2 включён у 98.6% (Ultimate) и 99.5% (Community). Для редких кейсов K1 ещё можно вернуть через VM-опцию, но режим считается устаревшим.
По производительности K2 даёт заметный прирост: анализ кода ускорился в среднем на 39%, Find Usages — на 34%, автодополнение — примерно на 26% благодаря параллельной обработке. В больших файлах ускорение особенно выражено.
Стабильность также выросла: меньше обращений в поддержку, меньше исключений в EAP, положительный фидбек от команд, работающих на крупных Kotlin-кодовых базах.
Функциональный паритет с K1 почти достигнут. Не перенесены лишь малопопулярные инспекции и рефакторинги (<0.5% использования).
Для тех, кто впервые слышит про K2, прикладываем материалы сообщества на эту тему:
– Новый компилятор K2 в Kotlin. Часть 1
– Новый компилятор K2 в Kotlin. Часть 2. Гайд по миграции
– IntelliJ IDEA 2024.3 EAP: Новые Возможности и Улучшения
@spring_aio
K2 — это полностью переработанный компилятор Kotlin, построенный на новой архитектуре. Он избавляет IDE от привязки к внутренностям старого компилятора и обеспечивает поддержку будущих языковых фич, стабильность и масштабируемость.
Адаптация почти завершена: среди пользователей версии 2025.2 K2 включён у 98.6% (Ultimate) и 99.5% (Community). Для редких кейсов K1 ещё можно вернуть через VM-опцию, но режим считается устаревшим.
По производительности K2 даёт заметный прирост: анализ кода ускорился в среднем на 39%, Find Usages — на 34%, автодополнение — примерно на 26% благодаря параллельной обработке. В больших файлах ускорение особенно выражено.
Стабильность также выросла: меньше обращений в поддержку, меньше исключений в EAP, положительный фидбек от команд, работающих на крупных Kotlin-кодовых базах.
Функциональный паритет с K1 почти достигнут. Не перенесены лишь малопопулярные инспекции и рефакторинги (<0.5% использования).
Для тех, кто впервые слышит про K2, прикладываем материалы сообщества на эту тему:
– Новый компилятор K2 в Kotlin. Часть 1
– Новый компилятор K2 в Kotlin. Часть 2. Гайд по миграции
– IntelliJ IDEA 2024.3 EAP: Новые Возможности и Улучшения
@spring_aio
👍26🔥5⚡4❤3
🙈Помогите, мой Java-объект исчез (и GC тут ни при чём)
Подготовили перевод офигенной истории от разработчика HotSpot.
Во время работы над Project Valhalla у него начали самопроизвольно пропадать Java-объекты и классы — без участия GC, без крэшей JVM, просто
Дальше начинается настоящий отладочный квест: разбор
История классная сразу в нескольких смыслах:
— по пути узнаёте, как реально устроены заголовки объектов в HotSpot и что делает Valhalla
— видите живой пример miscompilation в C2 и то, как её можно отловить
— получаете небольшой мастер-класс по методичной отладке больших систем: от минимизации тестов до аккуратной проверки гипотез
Ну а с концовки мы посмеялись) Аккуратнее, спойлер!!!
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/973214/
Подготовили перевод офигенной истории от разработчика HotSpot.
Во время работы над Project Valhalla у него начали самопроизвольно пропадать Java-объекты и классы — без участия GC, без крэшей JVM, просто
AssertionError, NoClassDefFoundError и странные null там, где им вообще неоткуда взяться.Дальше начинается настоящий отладочный квест: разбор
markWord и Compact Object Headers, эксперименты с флагами JVM, попытка изолировать баг между интерпретатором, C1 и C2, майнинг логов -XX:+PrintCompilation и CompileCommand, поиск подозрительных intrinsic-ов и, в итоге, выход на одну-единственную битовую маску, которая смотрела в указатель, а не в метаданные объекта.История классная сразу в нескольких смыслах:
— по пути узнаёте, как реально устроены заголовки объектов в HotSpot и что делает Valhalla
— видите живой пример miscompilation в C2 и то, как её можно отловить
— получаете небольшой мастер-класс по методичной отладке больших систем: от минимизации тестов до аккуратной проверки гипотез
Ну а с концовки мы посмеялись) Аккуратнее, спойлер!!!
Почему объекты превращались в null и почему классы «не находились» — я не знаю.
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/973214/
👍19❤9🔥8😁6🤯1
Forwarded from Amplicode
🤩 Прямой эфир про Spring Data JDBC!
Трансляция уже началась, присоединяйтесь!
В программе:
– Как правильно строить и использовать агрегаты в Spring Data JDBC.
– Почему API устроено так, как устроено — взгляд изнутри от участника разработки Spring Data.
– Фильтрация данных, удобные DTO, реализация бизнес-операций.
😉 СМОТРЕТЬ НА YOUTUBE
😄 СМОТРЕТЬ В VK ВИДЕО
🥰 СМОТРЕТЬ НА RUTUBE
Трансляция уже началась, присоединяйтесь!
В программе:
– Как правильно строить и использовать агрегаты в Spring Data JDBC.
– Почему API устроено так, как устроено — взгляд изнутри от участника разработки Spring Data.
– Фильтрация данных, удобные DTO, реализация бизнес-операций.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14❤9🔥9👎1
☠️ JetBrains закрывает Fleet
— легковесную IDE нового поколения, развиваемую параллельно с IntelliJ IDEA. Несмотря на технический успех и влияние на другие продукты компании, Fleet не смог занять устойчивую нишу.
Команда признала, что поддержка двух похожих линеек IDE лишь запутывала пользователей.
Вместо этого JetBrains переориентируется на новый вектор — агентную разработку, где код пишут AI помощники.
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/news/975182/
— легковесную IDE нового поколения, развиваемую параллельно с IntelliJ IDEA. Несмотря на технический успех и влияние на другие продукты компании, Fleet не смог занять устойчивую нишу.
Команда признала, что поддержка двух похожих линеек IDE лишь запутывала пользователей.
Вместо этого JetBrains переориентируется на новый вектор — агентную разработку, где код пишут AI помощники.
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/news/975182/
😁28🤯9🔥6🤔6❤3⚡2👍2
🏎 Hibernate Validator 9.1: самый мощный апгрейд за последние годы
Что, если ваш валидатор стал бы в 3 раза быстрее и потреблял бы вдвое меньше памяти — без единой правки бизнес-логики? Именно это случилось с Hibernate Validator 9.1: ушли тяжёлые коллекции, пришёл умный стек. Каскадная валидация теперь летает, даже при циклах в графе объектов.
Плюс бонус: меньше мусора в памяти, меньше аллокаций, быстрее интерполяция сообщений. В бенчмарках — просто космос. Все это – в новом переводе от команды Spring АйО.
Комментарий Поливаха Михаила:
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/975422/
Что, если ваш валидатор стал бы в 3 раза быстрее и потреблял бы вдвое меньше памяти — без единой правки бизнес-логики? Именно это случилось с Hibernate Validator 9.1: ушли тяжёлые коллекции, пришёл умный стек. Каскадная валидация теперь летает, даже при циклах в графе объектов.
Плюс бонус: меньше мусора в памяти, меньше аллокаций, быстрее интерполяция сообщений. В бенчмарках — просто космос. Все это – в новом переводе от команды Spring АйО.
Комментарий Поливаха Михаила:
Несмотря на то, что с валидацией мы напрямую работаем не часто, имейте в виду, что Spring Boot и ваши @RestController-ы под капотом всё равно используют hibernate-validator. Поэтому почитайте, не поленитесь 😉.📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/975422/
❤26👍19🔥12
Media is too big
VIEW IN TELEGRAM
💬 Аудио версию подкаста можно найти в комментариях
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10🔥10👍8⚡4
Forwarded from OpenIDE
This media is not supported in your browser
VIEW IN TELEGRAM
Мы готовы анонсировать версию OpenIDE Pro, в состав которой войдут:
• Расширенная поддержка Go, Spring, и фронтенд-технологий
• Мощные инструменты профилирования, диагностики и анализа кода
• Официальная поддержка и SLA для компаний
Сразу ответим на повисший в воздухе вопрос – бесплатная OpenIDE остаётся, развивается и будет только расти: Marketplace, LSP, Docker-плагин, новые языки в виде плагинов.
OpenIDE Pro – это та версию, которую можно использовать в компаниях официально и без риска!
Подробнее про OpenIDE Pro мы рассказали в новой статье на Хабре
Если хотите попасть в ранний доступ — пишите нам на: pro@openide.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
❤21👎15🔥10😁10👍5🤔5
Когда количество доступных LLM инструментов (tool-ов) разрастается, традиционные подходы к tool calling становятся непрактичными — утилизация токенов улетает ещё до начала общения. К тому же, модели становится сложнее выбрать нужный набор tool-ов для решения проблемы.
В новом переводе от команды Spring АйО читаем о паттерне Tool Search Tool, предложенном Anthropic и реализованном в Spring AI с помощью ToolSearchToolCallAdvisor. Он позволяет LLM динамически находить нужные инструменты по мере необходимости, экономя до 64% токенов и повышая точность.
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/976178/
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12👍6❤5