🎲 Сравнение собеседований в 8 крупных технологических компаниях
В новом переводе от команды Spring АйО Пунит Патвари недавно принял предложение о работе в Atlassian на должность ведущего инженера-программиста (Principal Software Engineer). За три месяца он прошёл более 60 собеседований в 11 компаниях, как он мне рассказал, и отказался ещё от трёх процессов после того, как согласился на предложение от Atlassian — включая собеседование в Meta.
* Meta признана экстремистcкой организацией в России
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/965926/
В новом переводе от команды Spring АйО Пунит Патвари недавно принял предложение о работе в Atlassian на должность ведущего инженера-программиста (Principal Software Engineer). За три месяца он прошёл более 60 собеседований в 11 компаниях, как он мне рассказал, и отказался ещё от трёх процессов после того, как согласился на предложение от Atlassian — включая собеседование в Meta.
* Meta признана экстремистcкой организацией в России
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/965926/
🔥19👍10❤4⚡3
🚀 Spring Framework 7.0 — новая эпоха Spring официально началась
Spring команда выкатили GA релиз Spring Framework 7.0 — это старт нового поколения фреймворка с фокусом на Java 25 и фундамент для Spring Boot 4.0, который на момент выпуска поста пока не вышел в GA.
Что нового:
🛑 Поддержка Java 25 (LTS) при сохранении baseline на Java 17
🛑 Переезд на Jakarta EE 11: Servlet 6.1, JPA 3.2, Bean Validation 3.1
🛑 Широкая адоптация JSpecify в рамках всей экосистемы Spring
🛑 Поддержка Jackson 3.0 (2.x пока можно, но уже deprecated)
🛑 Kotlin 2.2 и JUnit 6.0
Из новых фич, которые стоит посмотреть:
🛑 Программная регистрация бинов (более гибкий подход, чем XML/аннотации)
🛑 Core resilience features — встроенная устойчивость к сбоям
🛑 Новый JmsClient
🛑 API versioning на уровне фреймворка
🛑 Расширенная конфигурация HTTP Interface Client
🛑 RestTestClient для более удобного тестирования HTTP
Обратите внимание, что для Spring Framework 6 и 7 одинаковая baseline версия Java - 17. Если вы уже используете Java 17, то для перехода на Spring Framework 7 вам не потребуется повторно обновлять версию JDK.
Тем не менее, Java 25 постепенно станет дефолтом для enterprise-приложений на Spring
Spring команда выкатили GA релиз Spring Framework 7.0 — это старт нового поколения фреймворка с фокусом на Java 25 и фундамент для Spring Boot 4.0, который на момент выпуска поста пока не вышел в GA.
Что нового:
Из новых фич, которые стоит посмотреть:
Обратите внимание, что для Spring Framework 6 и 7 одинаковая baseline версия Java - 17. Если вы уже используете Java 17, то для перехода на Spring Framework 7 вам не потребуется повторно обновлять версию JDK.
Тем не менее, Java 25 постепенно станет дефолтом для enterprise-приложений на Spring
Please open Telegram to view this post
VIEW IN TELEGRAM
❤43👍22🔥13
Media is too big
VIEW IN TELEGRAM
💬 Аудио версию подкаста можно найти в комментариях
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤10🔥7👍5😁3
😭 Технический долг — это больно. А архитектурный?
В новой статье очень чётко объясняется, почему основная проблема не в «грязном коде», а в том, что фатальные перекосы рождаются на уровнях, куда разработчики обычно даже не смотрят.
На уровне приложений всё вроде просто: слишком много сервисов, половина — SaaS, данные лежат где попало. Это тот случай, когда «немного архитектурного долга» превращается в рост расходов и бесконечные сроки поставки.
А вот бизнес-слой — штука коварнее. Когда процессы не документированы, «владельцы» непонятны, а «фантомные» схемы живут в Confluence с 2017 года, компания начинает строить планы на неверных предпосылках. Тут уже не про код — тут про то, что неправильная схема процессов может парализовать пол-организации быстрее, чем любой упавший микросервис.
И наконец — стратегический уровень. Это та точка, где неверно определённые бизнес-возможности превращают многолетнюю стратегию в упражнение «стрельнули мимо, но уверенно». Стратегический долг редко заметен сразу, но именно он блокирует трансформации и закрепляет ошибочные решения на годы вперёд.
Вывод простой: архитектурный долг — это не про классы и паттерны, а про системную слепоту. Хорошая новость — архитекторы как раз и существуют для того, чтобы её лечить: собирать данные, строить модели, показывать несостыковки и помогать выбрать, где долг критичен, а где — допустим.
Статья на Хабр "Почему архитектурный долг опаснее технического?"
В новой статье очень чётко объясняется, почему основная проблема не в «грязном коде», а в том, что фатальные перекосы рождаются на уровнях, куда разработчики обычно даже не смотрят.
На уровне приложений всё вроде просто: слишком много сервисов, половина — SaaS, данные лежат где попало. Это тот случай, когда «немного архитектурного долга» превращается в рост расходов и бесконечные сроки поставки.
А вот бизнес-слой — штука коварнее. Когда процессы не документированы, «владельцы» непонятны, а «фантомные» схемы живут в Confluence с 2017 года, компания начинает строить планы на неверных предпосылках. Тут уже не про код — тут про то, что неправильная схема процессов может парализовать пол-организации быстрее, чем любой упавший микросервис.
И наконец — стратегический уровень. Это та точка, где неверно определённые бизнес-возможности превращают многолетнюю стратегию в упражнение «стрельнули мимо, но уверенно». Стратегический долг редко заметен сразу, но именно он блокирует трансформации и закрепляет ошибочные решения на годы вперёд.
Вывод простой: архитектурный долг — это не про классы и паттерны, а про системную слепоту. Хорошая новость — архитекторы как раз и существуют для того, чтобы её лечить: собирать данные, строить модели, показывать несостыковки и помогать выбрать, где долг критичен, а где — допустим.
Статья на Хабр "Почему архитектурный долг опаснее технического?"
❤19🔥13👍9
🔥 В Spring 7 завезли нативное версионирование API
База нововведения —
В контроллерах появляется новый атрибут
Хочешь гибкости — прописываешь
На клиентской стороне —
Тестовые клиенты работают по той же логике.
Статья на Хабр "Нативный API Versioning в Spring 7: долгожданная официальная поддержка"
Демо-проект с тестами и примерами
Документация
База нововведения —
ApiVersionStrategy. Он понимает, где искать версию (header, query, media type или путь), умеет её парсить как семантическую, знает поддерживаемый диапазон и может автоматически выставлять Deprecation/Sunset-заголовки. То есть вместо самодельных фильтров теперь есть один официальный механизм.В контроллерах появляется новый атрибут
version:
@GetMapping(path = "/account/{id}", version = "1.1")
public Account get() { ... }
Хочешь гибкости — прописываешь
"1.1+", и метод будет жить до тех пор, пока ты явно не создашь новую версию. Функциональные эндпоинты тоже подтянулись — у них теперь есть предикат version("1.2").На клиентской стороне —
ApiVersionInserter, который один раз настраиваешь:
RestClient client = RestClient.builder()
.baseUrl("http://localhost:8080")
.apiVersionInserter(ApiVersionInserter.useHeader("API-Version"))
.build();
// И дальше только версия
client.get().uri("/account/1")
.apiVersion(1.1)
.retrieve()
.body(Account.class);
Тестовые клиенты работают по той же логике.
Статья на Хабр "Нативный API Versioning в Spring 7: долгожданная официальная поддержка"
Демо-проект с тестами и примерами
Документация
❤39👍29🔥22🤩3🤔1🤯1
Forwarded from Amplicode
О программировании с помощью AI-агентов трубят из-за каждого угла. Последнее время появилось достаточно много инструментов, которые буквально пишут код за разработчика.
Наша команда следит за индустрией ИИ в разработке достаточно давно. Помимо внедрения ИИ в сам процесс разработки наших продуктов, мы активно занимаемся интеграцией Amplicode с современными AI-агентами и не только.
И у нас есть свои мысли на этот счет)
📚 Читать на Хабр: https://habr.com/ru/companies/haulmont/articles/925088/
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14❤7👍7
Spring Boot перешёл на новую мажорную версию — 4.0.0. Релиз состоялся 20 ноября 2025 года, его анонсировал Phil Webb от имени всей команды Spring. Новая версия построена на Spring Framework 7-ой версии.
Михаил Поливаха также выложил небольшую статью на Habr, где описал мотивацию за главным структурным изменением Spring Boot 4 - разбиением Spring Boot на модули.
Главное:
• Полная модульность: кодовая база переразбита на меньшие и точечно используемые JAR'ы.
• Null safety благодаря JSpecify: везде, по всем проектам Spring.
• Поддержка Java 25 (и сохранена совместимость с Java 17).
• API Versioning: встроенные средства управления версиями REST-API.
• HTTP Service Clients: новый стандартный способ описывать REST-клиентов.
Команда Spring предоставила отдельное руководство по миграции.
Материалы от сообщества Spring АйО на тему Spring 7 и Spring Boot 4:
• Нативный API Versioning в Spring 7: долгожданная официальная поддержка
• Jackson 3 ворвался в Spring
• Состояние HTTP-клиентов в Spring
• Spring Boot 4 и Spring Framework 7: Ключевые фичи и изменения
• Вышел Spring Framework 7.0
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥64👍26❤17
😎 Перестаньте думать и начните уже писать код!
Джефф Атвуд говорит вслух то, что многие думают, но редко признают. Можно часами гонять UML и вылизывать диаграммы, но без живого прототипа все эти решения — чистая фантазия на тему «как бы оно выглядело, если бы существовало».
Мысль статьи довольно жёсткая, но предельно понятная: сколько бы вы ни планировали, первый дизайн почти наверняка окажется неверным. И единственный способ принимать осмысленные архитектурные решения — писать код, получать обратную связь, менять подход и снова писать код. Итерации, а не медитации над белой доской.
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/967474/
Джефф Атвуд говорит вслух то, что многие думают, но редко признают. Можно часами гонять UML и вылизывать диаграммы, но без живого прототипа все эти решения — чистая фантазия на тему «как бы оно выглядело, если бы существовало».
Мысль статьи довольно жёсткая, но предельно понятная: сколько бы вы ни планировали, первый дизайн почти наверняка окажется неверным. И единственный способ принимать осмысленные архитектурные решения — писать код, получать обратную связь, менять подход и снова писать код. Итерации, а не медитации над белой доской.
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/967474/
👍31❤7🔥4⚡3🤔1
This media is not supported in your browser
VIEW IN TELEGRAM
🔥 Бесплатный оффлайн митап в МСК
На предстоящем Java Rock Stars Meetup для вас выступят две легенды из мира Java:
🟣 Роман Елизаров с докладом "От языков программирования к Developer Experience"
🟣 Алексей Рагозин с докладом "JDK Flight Recorder в Java 25"
Участие абсолютно бесплатное. Главное – зарегистрироваться!
P.S. Как классно было в прошлый раз можете оценить по прикрепленному шортсу)
На предстоящем Java Rock Stars Meetup для вас выступят две легенды из мира Java:
Участие абсолютно бесплатное. Главное – зарегистрироваться!
P.S. Как классно было в прошлый раз можете оценить по прикрепленному шортсу)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19❤9👍9
Михаил Поливаха, эксперт сообщества Spring АйО и контрибьютор в Spring, поделился своими мыслями по поводу issue под номером 35725, который на первый взгляд может показаться неоднозначным.
В версии Spring Framework 7.1 (предположительно) появится возможность нативно исполнять Python, JavaScript и другие noscripting-языки — благодаря интеграции с GraalPy, GraalJS и Truffle. Почему это вообще стало возможным?
GraalVM переживает перестройку: Oracle выводит проект из жёсткой привязки к Java SE, переосмысляет приоритеты и активнее ищет рынки для GraalJS/GraalPy. Эти направления продолжают активно развиваться — и как раз становятся фундаментом для будущей поддержки скриптов в Spring.
Важно: Spring и GraalVM исторически «дружат» ещё со времён Spring Native. Graal часто использует Spring Petclinic в своих демо, а Spring — один из ключевых потребителей AOT-технологий, Leyden и связанных инициатив. Поэтому усиление интеграции — логичный шаг.
Что это даст Spring?
— возможность встраивать скриптовые плагины, DSL и расширения без JVM-обвязки
— шанс усилить позицию в экосистеме AOT/fast startup
— поддержку Graal-линейки продуктов, что укрепляет союз с Oracle
Но стоит понимать и риски: новый API будет нишевым, а неаккуратное использование может легко привести к провалам в части security. Потому массовым решением это вряд ли станет.
Одним из драйверов всей инициативы считается Sébastien Deleuze — лидер Spring Framework, ранее создатель Spring Native и большой энтузиаст Kotlin и Graal. Многие в комьюнити отмечают, что благодаря его видению удалось «подтянуть» Spring к новой AOT-эпохе.
P.S. Эксперт сообщества Евгений Сулейманов отметил, что по его мнению ставка Spring на GraalVM — это не «хайп», а игра в долгую. Если Oracle найдёт устойчивые продуктовые ниши для GraalVM, Spring почти гарантированно станет дефолтным enterprise-фреймворком для полиглот-платформ нового поколения. Важно учитывать это, если вы планируете архитектуру на горизонте 5–7 лет.
@spring_aio
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯35👍18🔥6👎5⚡2❤2😁2
Media is too big
VIEW IN TELEGRAM
💬 Аудио версию подкаста можно найти в комментариях
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥26👍10❤8
🤩 Прямой эфир про Spring Data JDBC с Михаилом Поливахой
Онлайн, 9 декабря в 17:00 (МСК) команда Amplicode совместно со Spring АйО проведёт митап про Spring Data JDBC!
В программе:
– Как правильно строить и использовать агрегаты в Spring Data JDBC.
– Почему API устроено так, как устроено — взгляд изнутри от участника разработки Spring Data.
– Фильтрация данных, удобные DTO, реализация бизнес-операций.
Участие бесплатное. Обязательно зарегистрируйтесь, чтобы не пропустить.
🔗 https://events.amplicode.ru/spring-data-jdbc
Онлайн, 9 декабря в 17:00 (МСК) команда Amplicode совместно со Spring АйО проведёт митап про Spring Data JDBC!
В программе:
– Как правильно строить и использовать агрегаты в Spring Data JDBC.
– Почему API устроено так, как устроено — взгляд изнутри от участника разработки Spring Data.
– Фильтрация данных, удобные DTO, реализация бизнес-операций.
Участие бесплатное. Обязательно зарегистрируйтесь, чтобы не пропустить.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥26❤7👍6⚡1
⚡️ AOT-репозитории в Spring Data теперь доступны сразу в четырёх модулях
После почти полугода полировки Spring официально включили Ahead-of-Time репозитории в релизе 2025.1.0. Теперь AOT работает не только для JPA и MongoDB, но и для Cassandra и JDBC — и генерирует полноценный код репозиториев ещё на этапе сборки.
Главная фича — репозиторий больше не чёрный ящик. Генератор создаёт читаемый Java-код и JSON-метаданные, так что можно спокойно ставить брейкпоинты, видеть реальные запросы и понимать, что именно делает Spring Data. Для JPA, JDBC и Cassandra генерируется разный код — максимально близкий к конкретной технологии.
Плюс, AOT отлично дружит с новыми возможностями Java: репозитории и вспомогательный байткод могут попасть в AOT Cache и загружаться как готовые классы из shared objects. Это даёт ощутимый прирост времени старта и снижает потребление памяти.
Есть и нюансы: часть конфигурации «замораживается» (например, JdbcDialect нельзя динамически менять), сборка становится тяжелее, а reactive-репозитории пока не поддерживаются.
Но если вы хотите сервисы, которые стартуют быстрее, удобную отладку и меньше скрытой магии — AOT-репозитории выглядят как одно из самых интересных обновлений Spring Data за последние годы.
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/971364/
@spring_aio
После почти полугода полировки Spring официально включили Ahead-of-Time репозитории в релизе 2025.1.0. Теперь AOT работает не только для JPA и MongoDB, но и для Cassandra и JDBC — и генерирует полноценный код репозиториев ещё на этапе сборки.
Главная фича — репозиторий больше не чёрный ящик. Генератор создаёт читаемый Java-код и JSON-метаданные, так что можно спокойно ставить брейкпоинты, видеть реальные запросы и понимать, что именно делает Spring Data. Для JPA, JDBC и Cassandra генерируется разный код — максимально близкий к конкретной технологии.
Плюс, AOT отлично дружит с новыми возможностями Java: репозитории и вспомогательный байткод могут попасть в AOT Cache и загружаться как готовые классы из shared objects. Это даёт ощутимый прирост времени старта и снижает потребление памяти.
Есть и нюансы: часть конфигурации «замораживается» (например, JdbcDialect нельзя динамически менять), сборка становится тяжелее, а reactive-репозитории пока не поддерживаются.
Но если вы хотите сервисы, которые стартуют быстрее, удобную отладку и меньше скрытой магии — AOT-репозитории выглядят как одно из самых интересных обновлений Spring Data за последние годы.
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/971364/
@spring_aio
👍34🔥15❤5
⚡️ JSpecify пришёл в экосистему Java по-настоящему
В новой версии IntelliJ IDEA JSpecify теперь будет автоматически подтягиваться через зависимости: Spring Boot 4, Spring Framework 7, JUnit 6, Guava 33.4+.
Звучит классно, но на этапе тестирования фичи разработчики быстро упёрлись в некоторые проблемы. Стоило добавить
Причина проста – спецификация намеренно оставляла свободу в интерпретации опредлённых сценариев в коде, что приводило к разногласиям между инструментами, например, между IntelliJ как IDE, и NullAway как CI инструмента.
В итоге JSpecify рисковал превратиться в ещё одну спецификацию наряду с JSR 305.
JetBrains, Spring и команда NullAway провернули следующее: сели, разобрали кейсы, устаканили своё понимание спецификации и пришли к единому результату в IntelliJ IDEA 2025.3 и в NullAway:
🟣 Предупреждения IDE теперь совпадают с NullAway в тех же сценариях
🟣 Cмешанные аннотации мигрируются намного мягче
🟣 Suppressions стали переносимыми
Работа над спецификацией идёт дальше: обсуждаются единые suppression-идентификаторы, новые аннотации для тонких null-контрактов и способы облегчить миграцию больших приложений.
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/971390/
В новой версии IntelliJ IDEA JSpecify теперь будет автоматически подтягиваться через зависимости: Spring Boot 4, Spring Framework 7, JUnit 6, Guava 33.4+.
Звучит классно, но на этапе тестирования фичи разработчики быстро упёрлись в некоторые проблемы. Стоило добавить
@NullMarked, как IDE начинала закидывать сотнями предупреждений, причём даже в проектах, которые проходили NullAway на CI абсолютно чисто. Причина проста – спецификация намеренно оставляла свободу в интерпретации опредлённых сценариев в коде, что приводило к разногласиям между инструментами, например, между IntelliJ как IDE, и NullAway как CI инструмента.
В итоге JSpecify рисковал превратиться в ещё одну спецификацию наряду с JSR 305.
JetBrains, Spring и команда NullAway провернули следующее: сели, разобрали кейсы, устаканили своё понимание спецификации и пришли к единому результату в IntelliJ IDEA 2025.3 и в NullAway:
Работа над спецификацией идёт дальше: обсуждаются единые suppression-идентификаторы, новые аннотации для тонких null-контрактов и способы облегчить миграцию больших приложений.
📚 Читать на Хабр: https://habr.com/ru/companies/spring_aio/articles/971390/
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23❤12👍9⚡1
🔥 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