В новом переводе от команды Spring АйО рассматривается новое крупное обновление Gradle, которое приносит с собой переход на Kotlin 2 и Groovy 4, а также делает кеш конфигурации рекомендуемым режимом сборки. В версии 9 улучшена система отчётности об ошибках, ускорена компиляция Kotlin DSL, добавлена интеграция с Jspecify, снижено потребление памяти и оптимизирована работа с IDE.

---

Gradle 9.0.0 — это новое крупное обновление, которое включает множество изменений с момента выхода версии 8.0. В этой версии режим с использованием кеша конфигурации становится предпочтительным для выполнения сборок, улучшается система вывода ошибок, а также реализована поддержка Kotlin 2 и Groovy 4.

Комментарий от эксперта Spring АйО, Михаила Поливахи

Это довольно важное изменение с точки зрения безопасности да и в целом концепции immutable infrastructure. Reproducible сборки позволяют точно понять, тот артефакт/JAR что бежит у Вас в проде, он был ли собран из конкретно этих исходников, или что-то там было дополнительно изменено. Для сторонних зависимостей есть checksum verification и проверка сигнатур у Gradle, для ваших же проектов теперь есть также приятный инструмент

Ключевые обновления в Gradle 9

Ниже приведено краткое описание основных изменений между Gradle 8.0 и 9.0.0.

Примечание: обязательно ознакомьтесь с рекомендациями по обновлению (Upgrade Guidelines).

Как видно, мы переходим на формат версий из трёх цифр. Начиная с версии 9.0.0, Gradle будет придерживаться спецификации семантического версионирования (SemVer) для всех stable релизов.

Функции в статусе “incubating” и внутренние API могут иметь другую схему жизненного цикла и версионирования.

Кеш конфигурации

Кеш конфигурации — одна из самых востребованных функций Gradle последних лет. Независимо от того, используете ли вы Java, Kotlin, Android или проекты на нативных языках, эта функция может существенно сократить время построения конфигурации, особенно в больших кодовых базах. За последние годы было внесено множество улучшений, сделавших кеш конфигурации надёжнее, быстрее и удобнее как для разработчиков, так и для пользователей.

С выходом Gradle 9.0.0 кеш конфигурации становится рекомендуемым режимом, и мы настоятельно советуем всем пользователям Gradle начинать его использовать в своих сборках. Авторам плагинов также следует стремиться к совместимости с кешем конфигурации.

Комментарий от эксперта Spring АйО, Михаила Поливахи

Просьба не путать Configuration Cache с Build Cache и с инкрементальными билдами в Gradle вообще. Многие люди, которые работали с gradle, привыкли, что task может быть в статусе UP-TO-DATE. Это как раз проявление инкрементальной сборки, когда Gradle в локальной папке проекта .gradle хранит необходимые результаты ряда тасков, которые, при достижении ряда определенных условий, переисопльзуются.

Build Cache это по сусти расширение понятия инкрементальной сборки. Пробелма в том, что от инкрементальной сборки вы, как девелопер, конечно, получите ряд преимуществ на локальной машине в виде ускоренной сборки. Но когда ваш код будет собираться на агенте, то условный gradle wrapper на агенте будет вынужден прогнать всё дерево тасок заново, т.к. никакой кешированной информации нигде нет. Build Cache как раз позволяет вам определенным образом шарить результаты выполнения тасок уже между разными машинами, т.е. не только на вашей локальной workstashion.

Configuration Cache это совсем другое понятие. Это, грубо, кеш для построения дерева зависимых тасок и их параметров/конфигураций. Речь именно про этот кеш в данном случае.

Кеш конфигурации — предпочтительный режим выполнения

Для облегчения внедрения и повышения совместимости с плагинами, поддерживаемыми сообществом, теперь рекомендуется включать кеш конфигурации в большинстве случаев. Хотя в версии 9.0.0 кеш по умолчанию не включён, были внесены важные изменения:

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

• Для новых проектов, созданных через gradle init, кеш конфигурации включается по умолчанию.

• Инструменты разработчика и документация по кешу конфигурации были существенно доработаны для облегчения внедрения и отладки.

• Основные плагины и задачи Gradle теперь могут автоматически делать fallback и строить конфигурацию билда заново, даже если они несовместимы с кешем. Это позволяет включить кеш конфигурации на постоянной основе даже при использовании несовместимых плагинов, не опасаясь сбоев сборки - core плагины gradle будут самостоятельно, при обнаружении несовместимостей, собирать конфигурацию сборки.

• В Gradle 9 удалены многие устаревшие API, несовместимые с кешем конфигурации, в пользу безопасных и идиоматичных альтернатив. Эта работа по очистке и удалению устаревших функций будет продолжена в следующих версиях.

В будущих минорных релизах линейки Gradle 9.x.y мы сосредоточимся на совместимости плагинов, улучшении инструментов разработчика, повышении количества попаданий в кеш и общей производительности — с целью включить кеш конфигурации по умолчанию в Gradle 10.

Более подробно про релиз 9.0.0: 9.0.0 Changelog, Upgrade Guidelines

Шифрование кеша конфигурации

Начиная с версии 8.1, Gradle шифрует кеш конфигурации, чтобы снизить риск случайной утечки конфиденциальных данных. Gradle автоматически создаёт уникальный секретный ключ для машины, сохраняет его в домашней директории пользователя Gradle и использует для шифрования данных в кешах, связанных с конкретным проектом.

Полная поддержка проверки зависимостей

Gradle поддерживает верификацию зависимостей через дополнительные метаданные. Доступны как проверка по контрольным суммам, так и по цифровым подписям, в виде функции, включаемой по выбору. Начиная с версии 8.1, эта проверка полностью поддерживается в режиме выполнения с кешем конфигурации. Изменения в связанных файлах (например, в keyring или verification-metadata.xml) корректно отслеживаются и при необходимости сбрасывают кеш.

Комментарий от эксперта Spring АйО, Михаила Поливахи

В данном случае речь именно про то, что изменения в чексуммах для проверки зависимостей (они как раз хранятся в verification-metadata.xml) будут тригерить сброс кеша для конфигураций. Сам механизм верификации зависимостей уже относительно давно присутствует в Gradle.

Вообще верификация зависимостей это фича хорошая, но она сильно аффектит developer experience, поэтому, по моим налюдениям, используют её не часто.

Устранение дублирования строк

В Gradle 8.10 было внедрено значительное сокращение размера кеш-файлов благодаря устранению дублирования строк и ускорению загрузки кеша. Например, команда Android X сообщила о снижении размера кеша в 3,75 раза.

Параллельная загрузка и сохранение кеша конфигурации

В Gradle 8.11 производительность кеша была существенно улучшена за счёт параллельной загрузки и сохранения записей в этот кеш (см. release notes). По результатам тестов наблюдается значительный прирост в производительности, особенно при использовании параллелизации при построении кеша конфигурации. Один из пользователей сообщил о сокращении времени построения конфигурации на 50% при сборке с ~600 проектами — с 2 минут и 4 секунд до 55 секунд, при этом размер кеша уменьшился с 700 МБ до 400 МБ.

Подробнее: Gradle 8.11 Release Notes, Documentation Page, Blogpost by Inaki Villar

Другие улучшения производительности

Хотя кеш конфигурации уже даёт значительный прирост скорости, в Gradle реализованы и другие важные изменения, улучшающие общую производительность, особенно при сборке проектов и синхронизации с IDE.

Избежание компиляции Kotlin-скриптов

DSL на Kotlin предоставляет гораздо более удобную поддержку со стороны IDE, однако более длительное время компиляции по сравнению с Groovy может быть проблемой в крупных проектах. Совместно с командами JetBrains и Google мы продолжаем работать над ускорением сборок с использованием Kotlin DSL. Используя возможности Kotlin 2 (см. ниже), Gradle 9.0.0 ускоряет обратную связь (feedback loops) при редактировании логики сборки за счёт избежания ненужной перекомпиляции .kts-файлов.

В одном из примеров была зафиксирована 2,5-кратная прибавка в скорости выполнения команды :help после внесения изменений в сборку.

Снижение потребления памяти

В Gradle 8.1 и 8.3 были реализованы значительные оптимизации использования памяти при разрешении зависимостей. Это улучшение затрагивает большинство сборок, но особенно заметно оно в процессе синхронизации с IDE, особенно в сложных проектах с большим количеством операций разрешения зависимостей.

Повышение производительности IDE за счёт оптимизации Tooling API

Начиная с Gradle 8.8, была оптимизирована работа Tooling API при выполнении обширных графов задач, что дало прирост производительности до 12% в больших и актуальных сборках, содержащих более 15 000 задач. Обновление версии Gradle немедленно приносит выгоду таким инструментам, как Android Studio, IntelliJ IDEA, Eclipse и другим клиентам Tooling API.

Подробнее — в соответствующем разделе release notes.

Kotlin и Kotlin DSL

Kotlin DSL для Gradle использует язык Kotlin и обеспечивает полноценную поддержку со стороны IDE при создании сценариев сборки в IntelliJ IDEA и Android Studio. Это включает автодополнение, интеллектуальную подсказку контента, быстрый доступ к документации, переход к исходному коду и контекстную рефакторинг-поддержку.
С Kotlin DSL вы можете редактировать логику сборки с тем же уровнем удобства, что и обычный рабочий код. Поддержка Groovy DSL при этом сохраняется, и её снятие с поддержки не планируется. Мы продолжаем развивать интеграцию Kotlin DSL и улучшать производительность, начиная с Gradle 8.0.

Подробнее про Kotlin DSL в Gradle.

Kotlin DSL стал вариантом по умолчанию для новых сборок

В апреле 2023 года (Gradle 8.2) Kotlin DSL стал рекомендуемым вариантом для новых проектов на Gradle, и теперь он используется по умолчанию при gradle init и в официальном руководстве пользователя. Также Kotlin DSL стал стандартом для новых проектов в IntelliJ IDEA и Android Studio. Мы ожидаем, что большинство новых проектов в будущем будет использовать именно его.

Переход на Kotlin 2

Kotlin 2.0, выпущенный 21 мая 2024 года, стал важной вехой в развитии языка. Он включает множество улучшений, таких как более умный вывод типов, более точные smart cast'ы (даже после ||, внутри лямбд и в nullable-выражениях), а также более тесную интеграцию с Compose Multiplatform. В 2025 году вышли версии Kotlin 2.1.0 и 2.2.0 с дальнейшими улучшениями.

Gradle 9 включает последнюю стабильную версию рантайма Kotlin 2.2.x и использует версию языка Kotlin 2.2. Это отличие от Gradle 8.x, где с версии 8.11 был встроен Kotlin 2.0, но сохранялось использование языка версии 1.8 ради совместимости.
Разработчики, использующие Kotlin DSL или создающие плагины на Kotlin, теперь могут использовать новые возможности языка и получат улучшенную поддержку со стороны IDE и других инструментов. Однако Kotlin 2 содержит синтаксические и семантические изменения, нарушающие совместимость, поэтому при переходе на Gradle 9 может потребоваться адаптация сборки и плагинов.

Подробнее: Changelog Entry, Upgrade Guide

Улучшения в Kotlin DSL

В рамках линейки Gradle 8.x были внедрены многочисленные нововведения для улучшения опыта работы с Kotlin DSL. Среди ключевых нововведений:

• Простой синтаксис присваивания свойств через оператор = в версии 8.6

• API каталогов версий доступен в прекомпилированных скриптах с версии 8.5

• DSL для новых возможностей, особенно для вариаций (Variants) и атрибутов (Attributes)

• Отдельная документация по Kotlin DSL, созданная с помощью Dokka — с привычной структурой для разработчиков на Kotlin

• Улучшена интеграция с инструментами Kotlin: отчёты об ошибках и предупреждениях, возможность прерывать сборку при предупреждениях, проверки метаданных Kotlin

Читайте changelog для более подробной информации.

Более быстрая первая сборка

Начиная с Gradle 8.5, Kotlin-расширения для API Gradle включаются в дистрибутив. Благодаря этому первая сборка .gradle.kts-файлов выполняется быстрее — экономится около 4 секунд на мощных машинах. Особенно это заметно на временных CI-агентах и при кросс-версионном тестировании плагинов.

Переход на JSpecify и изменения в Kotlin Binary API

С Gradle 5.0 мы использовали аннотации JSR-305 для указания null-безопасности API Gradle. Начиная с Gradle 9, вместо них используются аннотации JSpecify. В сочетании с Kotlin 2.2 это даёт более строгую обработку nullable-типов и может приводить к изменению бинарного API.

Это изменение может затронуть все плагины и сборки, написанные на Kotlin, но также значительно снижает риск ошибок, связанных с null'ами. Подробнее — в соответствующем разделе migration guide.

Версии Java и инструментальные цепочки (Toolchains)

Gradle развивается вместе с Java, добавляя поддержку новых версий и возможностей для улучшения developer experience.

Java 17 — минимальная версия для запуска Gradle

С этого выпуска для запуска Gradle требуется Java 17. Обновите рантайм до этой версии.

Если вы собираете проекты на более ранних версиях Java, вы можете указать их через toolchains или использовать другие способы разделения версий для Gradle и сборки.

Рекомендуем ознакомиться с матрицей совместимости для более подробной информации по поддержке версий и конфигураций.

Подробнее: Changelog Entry, Upgrade Guide

Поддержка новых версий Java для сборки и запуска

Постепенно добавляется поддержка новых версий Java как для сборки, так и для запуска Gradle. Gradle 8.0 поддерживал Java до версии 19, а Gradle 9.0.0 поддерживает Java до версии 24 включительно.

Ознакомьтесь с матрицей совместимости для информации по текущему состоянию поддержки Java и рекомендациям.

Поддержка JAVA_HOME как источника для определения Toolchain

Начиная с Gradle 9.0.0, можно использовать переменную окружения JAVA_HOME для автоматического определения версии Java. Gradle теперь может находить и использовать версию Java, заданную этим способом.

Поддержка GraalVM в Toolchains

Начиная с Gradle 8.14, toolchain-ы в Gradle позволяют выбирать и использовать конкретные версии JDK для сборки, тестирования и запуска Gradle. Если задан флаг nativeImageCapable, Gradle будет выбирать только те JDK, которые поддерживают Native Image.

Подробнее: Documentation Entry

Улучшения Gradle Daemon

Toolchain для Gradle Daemon

Начиная с Gradle 8.8, пользователи могут указать отдельную JVM для Gradle Daemon, отличную от JVM, используемой в CLI. Gradle сначала попытается найти совместимую версию локально (auto-detection). С версии 8.13 добавлена автоустановка нужной версии Daemon JVM (auto-provisioning) при её отсутствии.

С Gradle 8.10 также появилась возможность указывать вендора JVM. Gradle будет выбирать только ту JVM, которая соответствует как нужной версии, так и указанному вендору. Подробнее тут.

Больше информации по Daemon JVM criteria в пользовательском гайде.

Более быстрая компиляция за счёт постоянного daemon-ов компилятора

Gradle 8.3 ускоряет компиляцию Java на Linux и macOS за счёт сохранения daemon-ов в памяти между сборками. Внутренние тесты показали до 30% прироста в скорости сборки. С версии 8.4 такая же поддержка появилась и для Windows.

Поддержка слежения за файловой системой в Alpine Linux

Теперь Gradle поддерживает отслеживание изменений в файловой системе на Alpine Linux — популярном дистрибутиве для контейнеров и стандарте по умолчанию в Docker.

Обновление с Groovy 3 до Groovy 4

Gradle теперь использует последнюю stable версию Groovy 4.0 — это крупное обновление по сравнению с Groovy 3.0, применявшейся в Gradle 7 и 8. Groovy 4 включает множество нововведений и улучшений.

В Gradle Groovy используется для:

• скриптов сборки на Groovy DSL (.gradle файлы);

• логики сборки в common и convention plugins;

• интеграции с Ant.

Как и при любом крупном обновлении, поведение некоторых функций изменилось. В основном это затрагивает плагины, написанные на Groovy, а не сами скрипты сборки. В результате это может повлиять на сборки, использующие такие плагины (например, проблема #1469 в Shadow Plugin, уже решена). При обновлении до Gradle 9 обязательно проверьте совместимость используемых вами плагинов.

Подробнее: Changelog Entry, Upgrade Guide

Создание сборок (Build authoring)

В Gradle мы стремимся обеспечить максимально комфортную работу разработчикам, особенно тем, кто только начинает работать со сборками. Независимо от того, используете ли вы Gradle из командной строки, через IDE или в системе CI/CD, Gradle 9 должен улучшить ваш user experience. Это касается как DSL и API для создания сборок, так и улучшенных инструментов для устранения ошибок и сбоев синхронизации.

API проблем (Problems API)

Одним из ключевых нововведений в линейке 8.x стал API для работы с проблемами. Он уже помогает в ряде случаев, таких как deprecated функции, совместимость с кешем конфигурации, предупреждения при компиляции и др.

HTML-отчёт о проблемах

Начиная с Gradle 8.11, все проблемы в сборке выводятся не только в консоль и через API, но и в виде отдельного HTML-отчёта. Это централизованное место, где можно просмотреть все проблемы сборки — как из внутренних, так и внешних плагинов. Отчёт включён по умолчанию, а ссылка на него отображается в консоли.

Улучшенная отчётность об ошибках

Система вывода ошибок в Gradle значительно улучшилась между релизами. Внесены следующие изменения (но не ограничиваясь ими): подавление дублирующих сообщений об ошибках с одной и той же причиной, подробные сведения при промахах кеша конфигурации, более чёткая отчётность при сбоях применения плагинов и при несовпадении JVM.

Все изменения:

• Подавление дублирующих сообщений об одной и той же причине ошибки — 8.8

• Улучшенная отчётность при сбоях задач компиляции Java — 8.10

• Подробная информация о промахах мимо кеша конфигурации — 8.9

• Улучшенная отчётность при ошибках применения плагинов — 8.7

• Более чёткие рекомендации при ошибках блокировки зависимостей — 8.6

• Вывод ошибок задач копирования — 8.7

• Улучшенная отчётность при несовпадении версий JVM — 8.8

• Улучшенная обработка ошибок в резолверах toolchain'ов — 8.8

• Исправлен вывод ошибок при отключенных репозиториях — 8.8

• Отчётность об ошибках при неоднозначности вариантов и их отсутствии — 8.9

• Обнаружение и вывод информации о неоднозначных цепочках преобразования артефактов — 8.12

Поддержка тестового прогона (Test Dry Run)

При тестировании проекта может быть полезно узнать, какие тесты будут запущены, не выполняя их фактически — особенно при использовании API для фильтрации тестов.
Gradle 8.3 представил режим "тестового прогона", который можно включить с помощью флага командной строки --test-dry-run или свойства dryRun.

Этот режим совместим с фреймворками JUnit и TestNG.

Улучшенная отчётность о пропущенных тестах

Начиная с версии 8.14, если тест пропускается из-за нарушения предположения (assumption), Gradle теперь указывает причину пропуска как в HTML, так и в JUnit XML отчётах. Это работает с JUnit 4, JUnit Platform и TestNG.

Подробнее тут.

Улучшения в Build Init

Механизм инициализации сборок Gradle получил ряд улучшений для соответствия новым возможностям и лучшим практикам:

• Kotlin DSL по умолчанию при генерации сборки — с 8.2

• Поддержка конвертации проектов Apache Maven в Gradle — с 8.2 (подробнее в Migration Guide)

• Генерация сборок с каталогом версий — с 8.5

• Поддержка параметра Java-версии — с 8.5

• Возможность пропустить интерактивные вопросы — с 8.6

• Включение кеша конфигурации по умолчанию — с 8.11

Дополнительные функции Build Init доступны через отдельные плагины, включая генерацию декларативных сборок Gradle.

Дополнительные улучшения

В Gradle также было реализовано множество мелких улучшений и доработок. Некоторые из ключевых:

• Улучшения в API Variants для упрощения получения зависимостей на основе атрибутов и возможностей

• Новый TestEventReporting API (8.13), позволяющий выводить события тестов вне стандартной задачи Test

• Преобразования артефактов: отчётность о задачах (см. release notes Gradle 8.13) и обнаружение неоднозначных цепочек (см. release notes Gradle 8.12). Преобразования теперь также отображаются в Build Scan.

Повышение безопасности цепочки поставок

Gradle продолжает инвестировать в безопасность цепочки поставок. Важно обеспечить воспроизводимость сборок и возможность анализа их содержимого. Также приоритет — отслеживание зависимостей и уязвимостей.

Воспроизводимые архивы по умолчанию

Gradle теперь по умолчанию создаёт воспроизводимые архивы: содержимое JAR, ZIP и других Java-пакетов идентично байт-в-байт. Ранее такие параметры (метки времени, порядок файлов, права) были доступны с версии 3.4, теперь они настроены по умолчанию.

Это шаг к надёжным и верифицируемым сборкам, особенно важным при поставке ПО.
Важно: это может повлиять на сборки, зависящие от специфического порядка файлов, изменяемых меток времени или прав доступа. Возможно, потребуется перенастроить задачи архивирования.

Подробнее: Changelog, Upgrade Guide

GitHub Actions и Dependency Submission

В рамках партнёрства с GitHub по безопасности цепочки поставок была выпущена новая Dependency Submission Action для Gradle. Она автоматически отправляет список зависимостей в граф зависимостей GitHub и активирует Dependabot для отслеживания уязвимостей.

С мая 2025 GitHub поддерживает автоотправку зависимостей для Gradle, а с июня — поддержку lock-файлов Gradle в Dependabot.

Улучшения Gradle Wrapper

• Поддержка symbloic имен версий — с 8.1

• Проверка доступности URL дистрибутива — с 8.2

• С Gradle 9 стало возможно указывать версии с неполной спецификацией SemVer, например, просто 9 или 9.1 вместо полной 9.1.0

Подробнее — в release notes.

Другие фичи

Выше приведены только ключевые изменения Gradle 9.0.0 и важные темы минорных релизов. В релиз также вошли десятки мелких улучшений, исправлений и удалений устаревших API. Некоторые встроенные плагины Gradle, например для статического анализа и нативной поддержки, также получили значительные обновления.

Эти изменения могут быть важны для некоторых пользователей. Они доступны в журнале изменений Gradle или на страницах документации соответствующих плагинов.

Build Scan и интеграция с Develocity

Gradle предоставляет бесплатный сервис Build Scan, позволяющий анализировать сборки, выявлять узкие места, отслеживать зависимости и получать глубокие метрики. Он реализован через плагин Develocity Gradle, который активно развивается.

Между Gradle 8.0 и 9.0.0 были реализованы следующие функции:

• Группировка сбоев сборки и тестов на основе ИИ

• Отчёты об использовании ресурсов среды сборки: CPU, RAM, сеть, диск

• Анализ преобразований артефактов

• Метрики и отчётность по кешу конфигурации, включая причины промахов

• Поддержка изолированных проектов во всех возможностях Build Scan и Develocity

• Улучшения в отчётах по предсказательному выбору тестов и экономии при параллельном запуске

• Расширенные API и DSL для настройки плагина

• Улучшенная визуализация ключевых метрик, вывода CLI и отчётов

Если вы ещё не пробовали Build Scan, ознакомьтесь с коротким курсом Gradle Build Scan в DPE University, который предлагает пошаговое знакомство с основными функциями этого инструмента.

Подробнее: Build Scan Documentation, Develocity release notes, Develocity Gradle Plugin release history.

Обновления документации

Руководство пользователя Gradle — один из самых популярных ресурсов, и его развитие продолжается. Между Gradle 8.x и 9.x были внесены крупные изменения:

• Полная реструктуризация руководства: ключевые функции вынесены на отдельные страницы, улучшена навигация

• Новый поисковый движок — Algolia DocSearch v3, настроенный под документацию Gradle

• Обновлены примеры кода — они соответствуют современным лучшим практикам, доступны для копирования, а также можно скачать рабочие проекты

• Введена новая форма обратной связи для предложения улучшений

• Примечания к релизам теперь имеют якоря для быстрой навигации

• Опубликована экспериментальная Gradle Cookbook — открытая коллекция рецептов и примеров интеграции

• Опубликовано руководство по лучшим практикам, помогающее освоить рекомендуемые паттерны и избежать типичных ошибок. Эта инициатива реализуется совместно с Google и JetBrains и будет дополняться в следующих версиях.

Вся документация остаётся с opensource, и мы приглашаем вас внести свой вклад! Ознакомьтесь с Руководством для контрибьютеров.

Обучающие материалы и курсы

В мае 2024 года компания Gradle, Inc. запустила новый бесплатный обучающий портал — DPE University, заменивший старые курсы на gradle.org и устаревшие руководства Gradle.

Новый портал включает множество самостоятельных обучающих курсов, предназначенных как для начинающих разработчиков, так и для инженеров по сборке, использующих Gradle или Develocity.
По завершении отдельных курсов можно получить сертификат, который можно разместить, например, в профиле LinkedIn.

Обновлённые сайты Gradle

В мае 2025 года сайт gradle.org получил обновлённый дизайн!
Кроме нового внешнего вида, была переработана структура навигации — теперь проще находить ключевые ресурсы: документацию, обучающие материалы и описания функциональности. Также была обновлена техническая основа сайта, что позволит быстрее внедрять улучшения и обновления.

Дополнительные изменения в ресурсоориентированной экосистеме Gradle:

• Новостная рассылка и блог Gradle получили новый дизайн, поддержку оглавлений и якорей по разделам — теперь проще делиться конкретной информацией. Также доступна подписка через RSS.

• Запущен новый открытый сайт сообщества Gradle, где собраны ресурсы для контрибьюторов: руководства, мероприятия (включая участие в Google Summer of Code) и др.

• Опубликован отдельный сайт проекта Declarative Gradle, посвящённый новому декларативному подходу к созданию сборок.

Исключённые / Не включенные в релиз функции

Миграция на Provider API

Миграция на Provider API направлена на внедрение ленивой конфигурации и унификацию API для Kotlin DSL и Groovy DSL. 28 марта 2025 года было принято решение исключить эту миграцию из состава Gradle 9. По результатам ранней обратной связи выяснилось, что для успешного перехода критически важна качественная поддержка со стороны IDE. Это требует улучшений как внутри Gradle, так и в IntelliJ IDEA и Android Studio.

Мы сохраняем приверженность миграции на Provider API и активно работаем над завершением перехода оставшихся свойств. Цель — включить миграцию в Gradle 10, релиз которого запланирован на 2026 год.

Статус Isolated Projects

Isolated Projects — это экспериментальная (pre-alpha) функция Gradle, которая расширяет кеш конфигурации и позволяет существенно улучшить производительность, особенно при синхронизации с Android Studio и IntelliJ IDEA.
Хотя ранее появлялись сообщения о том, что эта функция будет в статусе incubating в Gradle 9.0, в реальности её продвижение запланировано на последующие релизы линейки 9.x.

Gradle 9.0.0 не содержит изменений, связанных с Isolated Projects. Приоритет был отдан выводу кеша конфигурации в стабильное состояние, поскольку он является базисом для Isolated Projects. После завершения этой работы, разработка Isolated Projects будет продолжена.

Переход на Gradle 9

Как и при любом крупном обновлении, переход на Gradle 9 требует осторожности, так как содержит ряд изменений, нарушающих обратную совместимость. Среди них:

• Повышение минимальной требуемой версии Java

• Удаление deprecated API и функций

• Изменения в DSL на Kotlin и Groovy из-за перехода на Kotlin 2 и Groovy 4

• Изменения в бинарных API для Kotlin-плагинов из-за внедрения аннотаций JSpecify

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

Хотя мы ожидаем, что большинство пользователей смогут перейти на Gradle 9 без серьёзных проблем, всё зависит от конкретной архитектуры и сложности проектов.

---

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано