Grails 8 Is Coming: What's New and What It Means for Java Teams

Grails 8 represents the next major step in the evolution of the Grails framework. This release focuses on long-term stability, ecosystem alignment, and modernizing the foundation that Grails applications rely on in production.

In my role as VP and chair for Apache Grails, I’ve been guiding the team developing Grails 8. Read on for an inside look at the recent transformation of Grails into an Apache Software Foundation project, what is arriving in Grails 8, why these changes were made, and what Java development teams should be thinking about as they prepare to adopt Grails 8. 

I’ll also cover the release timeline, major platform changes, deprecations, and practical guidance for upgrading existing Grails applications to Grails 8.

A New Chapter for Grails at the Apache Software Foundation

In September 2025, after an 18-month migration effort, Apache Grails graduated from incubation to become a Top-Level Project (TLP) at The Apache Software Foundation (ASF). For a framework that has been in continuous development since 2005, this was the most significant governance change in its history, and it reset the foundation on which every future Grails release — including Grails 8— will be built.

Governing, Developing, and Releasing Grails Under the Apache Software Foundation

The move to the ASF changed how Grails is governed, developed, and released. Ownership shifted from a single-organization model (Grails was previously stewarded in turn by G2One, SpringSource, Object Computing, and the Grails Foundation/Unity Foundation) to a volunteer-driven, vendor-neutral Project Management Committee operating under "the Apache Way" of consensus and transparency. 

Decisions now happen on public mailing lists, code reviews are open, and releases follow ASF policy for licensing, provenance, and reproducibility. For enterprise teams, that translates into a clearer paper trail, predictable governance, and no single point of corporate failure.

The technical work behind the transition was substantial. 

Changes included:

• GitHub Repository Consolidation: The Grails team consolidated more than 24 separate GitHub repositories into a single grails-core mono-repo that now produces over 325 published JAR files across 109 Gradle projects. 
• Accelerated Build Times: Build times for a Grails release dropped from three weeks to roughly 30 minutes. 
• Unified Maven Coordinates: Maven coordinates were unified under org.apache.grails, every published artifact was reviewed for license compliance, and a Software Bill of Materials (SBOM) is now generated for every JAR. The build system itself was made reproducible end-to-end so that any third party can independently verify a release — a capability that benefits downstream Grails applications as much as it does the framework.

The Revitalized Grails Community 

Just as importantly, the ASF transition has visibly revitalized the community. Grails 7 was the first stable release shipped under the ASF, and it pulled in contributions from a much broader cast of committers than recent prior releases — including significant contributions back to Apache Groovy itself. New committers, new mailing lists, a refreshed Slack workspace, and a more active issue tracker have all followed. 

This shift most directly affects long-term framework adoption: a framework with one maintainer is fragile, butone with dozens of active contributors at an established foundation is not. It’s important to look at the Grails 8 release in the context of that renewed momentum.

Renewed Momentum for Grails

Grails 8 is the first major version planned and executed entirely under ASF stewardship, and it reflects the project's confidence in its new operating model. The roadmap is no longer constrained by what one organization can fund; it’s set by where the broader JVM ecosystem is heading and where the volunteer team has the capacity to lead.

A Look Back at Grails 7

To understand where Grails 8 is headed, it helps to see what Grails 7 already delivered. Released on October 18, 2025, Grails 7.0.0 was the first stable release under ASF leadership. It serves as the technical groundwork for everything Grails 8 builds on top of.

Java Modernization With Grails 7

Grails 7 modernized the entire stack. It moved to Apache Groovy 4.0.x, Spring Boot 3.5.x, Spring Framework 6.2.x, and Jakarta EE 10 (the long-awaited javax.* -> jakarta.* migration), and it required Java 17 as a minimum. Maven coordinates were rebased onto org.apache.grails, the grails-i18n plugin was relocated to its own coordinates and made transitive by default, and the entire build was made byte-for-byte reproducible with SBOMs for every JAR. The Grails Forge application generator (start.grails.org) and a lightweight Grails Wrapper (grailsw, ~25KB) shipped as first-class CLIs alongside the legacy shell. Functional testing got a refresh with Geb 8 and containerized browser support, and cloud.wondrify.asset-pipeline 5.x replaced the older Asset Pipeline coordinates.

Grails 7 also did the unglamorous but necessary work of pruning. Multi-project reload support was added for modular applications, and a long list of deprecated APIs from the Grails 5 and 6 eras were either removed or scheduled for removal in 8. In other words, Grails 7 spent its release cycle aligning the framework with the modern JVM, getting the project to ASF policy compliance, and clearing the runway. Grails 8 is what the team builds with that runway clear.

Grails 8: Release Timeline and Strategy

Grails 8 has been developed with a clear goal: align the framework with the modern JVM ecosystem while providing a stable, forward-looking foundation for enterprise Grails applications. The release timeline reflects that priority, balancing necessary platform shifts with a strong commitment to predictable upgrades.

Release Window for Grails 8

Grails 8 development began in late November 2025, immediately following the Spring Boot 4.0.0 GA. The first public milestone, Grails 8.0.0-M1, was published on May 6, 2026, with subsequent milestones, release candidates, and the 8.0.0 General Availability release tracking the maturity of the underlying platform stack. Until 8.0.0 GA, teams should treat 8.0.x milestones as preview builds suitable for evaluation and migration planning rather than production deployment.

Platform Alignment Drives the Grails 8 Release Cadence

Grails 8 is intentionally tied to Spring Boot 4.0 and Spring Framework 7.0. This is why M1 did not arrive sooner: the framework will not ship a major release on a pre-GA Spring stack. Once 8.0.0 GA is published, the project plans to maintain a cadence of monthly 8.0.x patch releases that follow Spring Boot's own monthly cadence, with out-of-band releases for security and urgent fixes.

Overlapping Lifecycles for Grails 7 and Grails 8

The 7.0.x line continues to receive full updates and maintenance until the Spring Boot 3.5.x end-of-life on June 30, 2026. That gives teams a clear runway: they can stay on Grails 7 while Spring Boot 3.5 is supported, plan their Grails 8 migration during that window, and avoid the trap of running on an unsupported underlying platform. Grails 6.2.3 (released January 3, 2025) was the final 6.2.x release and the last pre-ASF release; teams still on Grails 6 should plan a migration to 7.0.x first, then to 8.0.x, rather than attempting a single-step jump.

Design Goals Behind Grails 8

Every major Grails release is driven by a small number of core goals. For Grails 8, those goals are centered on longevity, clarity, and interoperability.

• Longevity: Grails 8 aligns the framework with platforms that have multi-year support windows: Java 21 LTS, Spring Boot 4.0.x, Jakarta EE 10, and Hibernate 7. By tracking the long-term branches of its core dependencies (and by removing classes and APIs that pinned the framework to older versions of those dependencies) Grails 8 is positioned to receive security and feature updates without disruptive rewrites. The mono-repo, reproducible builds, and SBOMs introduced under the ASF transition further reduce the maintenance burden so the project can sustain that cadence.
• Clarity: Grails 8 deletes a substantial amount of legacy code — including the original JSONBuilder, the Mixin AST transform, deprecated EnumMarshaller classes, the legacy named-query infrastructure (NamedCriteriaProxy, NamedQueriesBuilder), the AetherGrapeEngine, deprecated plugin filters, and several long-deprecated MongoEntity and tag library methods. The result is a smaller, more focused public surface area where the recommended way to do something is also the only way. This change makes the Grails framework easier to learn and easier to support.
• Interoperability: Spring Boot 4 modularized its auto-configuration into domain-specific modules (spring-boot-webmvc, spring-boot-servlet, spring-boot-mongodb), Spring Framework 7 dropped its own org.springframework.orm.hibernate5 package and adopted JSpecify nullability annotations, and Jackson 3 replaced Jackson 2 as the default JSON mapper. Grails 8 absorbs all of those changes upstream so that teams who consume Spring or Jakarta APIs directly inside their Grails application get the modern, supported versions without fighting Grails for them.

Modern JVM and Jakarta Alignment With Grails 8

Grails 8 explicitly aligns with the current generation of JVM and Jakarta standards.

The Hibernate 7 upgrade is being landed via PR #15568, a substantial body of work that sits behind the 8.0.x-hibernate7 branch and replaces the previous attempt in PR #15530. It is expected to merge before 8.0.0 GA, which is why M1 should be treated as a preview of the platform shift rather than its final form.

This alignment is necessary because Spring Framework 7 and Spring Boot 4 are designed around Java 17+, Jakarta Servlet 6.1, and the new modular auto-configuration layout. Staying on the older stack would have forced Grails to backport security fixes indefinitely; instead, the framework moves with its foundation.

Reducing Legacy Drag With Grails 8

A meaningful portion of the Grails 8 work is deletion. The following were removed by PR #15565:

•  The legacy JSON/XML EnumMarshaller
• The JSONBuilder (superseded by StreamingJsonBuilder)
• The old Mixin/MixinTargetAware/MixinTransformation machinery
• The deprecated ConstraintsEvaluator
• The CompatibilityPluginFilter and the entire PluginFilter hierarchy
• The BinaryGrailsPluginDescriptor
• The CorePluginFinder
• AetherGrapeEngine/AetherGrapeEngineFactory
• The original gson-views JSON generator classes
• The GORM AutoTimestamp annotation and the NamedCriteriaProxy/NamedQueriesBuilder named-queries infrastructure (the test class for which alone was over 1,000 lines)
• The grails-events-compat shim
• Deprecated methods on GrailsApplication, GrailsPluginManager, MongoEntity, FormTagLib, and ApplicationTagLib

None of these were popular APIs by 2026, but each one carried test infrastructure, documentation, and a non-zero compatibility tax. Removing them shrinks the surface area Grails has to defend against future Spring, Groovy, and Hibernate changes, and it makes the remaining APIs easier to learn, document, and support.

Production-First Focus for Grails 8

Grails 8 is being designed against the realities of running Grails in production:

• Observability defaults are sensible out of the box. Spring Boot 4's liveness and readiness probes are exposed by default on the Health endpoint, which means Kubernetes deployments get correct probe behavior without per-app boilerplate.
• Reproducible, attestable builds. Every published JAR ships an SBOM, and the build is reproducible end-to-end so security teams can verify provenance.
• Logging defaults match modern infrastructure. Logback now defaults to UTF-8 for log files, aligning with Log4j2 and with most container log scrapers.
• Predictable plugin compatibility signals. The Grails Gradle Plugin will fail fast at configuration time when it detects incompatible setups (for example, using grails-micronaut without enforcedPlatform on the BOM), rather than letting builds fail in obscure ways at runtime.

What's New in Grails 8

Grails 8 introduces a set of changes that impact how applications are built, configured, and run. Some of these will feel incremental, while others reflect deeper platform shifts.

Core Framework and Dependency Updates

The headline changes in Grails 8.0.0-M1 include:

• Spring Boot 4.0.5 and Spring Framework 7.0.6 (PR #15541).
• Spring Boot autoconfigure modularization. The monolithic spring-boot-autoconfigure JAR is gone; auto-configuration classes live in domain-specific modules such as spring-boot-webmvc, spring-boot-servlet, and spring-boot-mongodb. Grails 8 absorbs the new layout via a split BOM (PR #15608).
• Jackson 3 (tools.jackson.*) is the default JSON mapper. Jackson annotations remain at com.fasterxml.jackson.annotation.* and are explicitly permitted alongside Jackson 3, so DTOs and domain classes do not need to change. Spring Boot's helper classes were renamed (Jackson2ObjectMapperBuilderCustomizer to JsonMapperBuilderCustomizer, @JsonComponent to @JacksonComponent, etc.).
• Hibernate 7 is in-flight via PR #15568 on the 8.0.x-hibernate7 branch. Grails 8.0.0-M1 itself still ships Hibernate 5.6.15.Final.
• Spring Framework 7 dropped org.springframework.orm.hibernate5 entirely. Grails 8 vendors that package into a new grails-data-hibernate5-spring-orm module under org.grails.orm.hibernate.support.hibernate5, so Grails-managed Hibernate integration continues to work seamlessly. Applications that import those Spring classes directly need to update the package name.
• Spring Security updates (PR #15609) and a refreshed grails-spring-security plugin track on a parallel release.
• Gradle 9.4.1 toolchain and a Micronaut 4 / Micronaut Platform 5 refresh across the Grails Forge generator and the grails-micronaut integration (PR #15365).
• JLine 3.30.6 and Jansi 2.4.2 for the Grails Shell CLI (PR #15367).
• Geb 8.0.1 for browser-based functional testing, JUnit 6.0.3, Spock 2.3-groovy-4.0.
• Asset Pipeline 5.1.0-M4 under the cloud.wondrify coordinates introduced in Grails 7.

Java Version Baseline for Grails 8

Grails 8 requires Java 21 to both build and run applications, up from Java 17 in Grails 7. Java 21 is a Long-Term Support release with broad ecosystem support. The Grails team chose 21 over a more aggressive baseline (such as Java 25, which is also LTS) for two practical reasons.

1. LTS alignment with the existing tooling ecosystem: Java 21 has multi-year vendor support across OpenJDK distributions (Temurin, Corretto, Liberica, Microsoft Build of OpenJDK, Oracle, Semeru), which matches the support window most enterprise teams budget for. Java 25 is newer and equally LTS, but tooling ecosystems (build agents, container images, IDE integrations, third-party plugin compatibility matrices) typically take six to twelve months to fully catch up to a new LTS.
2. Predictability for plugins: Grails has a sizable third-party plugin ecosystem. A Java 21 baseline lets those plugins target a stable bytecode level and a stable set of standard-library APIs without chasing preview features or finalized JEPs from later releases.

There is one important exception: applications that use the grails-micronaut integration must run on JDK 25 or later. This is not a Grails decision but a Micronaut one:Micronaut Core's io.micronaut.core.propagation.ScopedValues references java.lang.ScopedValue.CallableOp, which only exists in JDK 25 (the inner type was renamed from Callable to CallableOp when JEP 506 finalized ScopedValue). Running Micronaut on JDK 21 through JDK24 fails at runtime with NoClassDefFoundError: java/lang/ScopedValue$CallableOp. The Grails Forge generator enforces this requirement at generation time, and the Grails Gradle Plugin will surface a clear error if the JDK is too old. Applications that do not use any Micronaut integration are unaffected and run on JDK 21.

Configuration and Convention Updates

A handful of Spring Boot 4 changes propagate into Grails configuration:

• MongoDB property namespace: spring.data.mongodb.* is now spring.mongodb.* for Spring Boot's own auto-configuration. The Grails GORM for MongoDB plugin uses its own mongodb.* namespace, which is unaffected.
• Jackson property reorganization: spring.jackson.read.* and spring.jackson.write.* moved under spring.jackson.json.read.* / spring.jackson.json.write.*. The spring-boot-properties-migrator dependency will warn at boot time for most of these.
• Enum serialization default: As announced in the Grails 7.0.2 deprecation notice, SimpleEnumMarshaller is now the default for JSON and XML enum serialization. Enums serialize as string values (e.g., "SUBMIT") instead of the verbose legacy format with type metadata. Applications that previously opted in via grails.converters.json.enum.format: simple can remove that configuration.
• Spring Boot starter renames: spring-boot-starter-web is now spring-boot-starter-webmvc, spring-boot-starter-aop is now spring-boot-starter-aspectj, and the OAuth2 starters were renamed under the security- prefix (spring-boot-starter-security-oauth2-client, etc.). For lower-friction migrations, Spring Boot 4 ships a transitional spring-boot-starter-classic that pulls in the full module set, but new code should target the modular starters.
• WAR deployment: External-container WAR deployments now use spring-boot-starter-tomcat-runtime instead of the previous providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat' idiom. Embedded Tomcat (the default for ./gradlew bootRun and bootable WARs) continues to use spring-boot-starter-tomcat unchanged.

Build, Tooling, and Developer Experience

• Gradle managed version overrides:PR #15467 replaces the Spring Dependency Management plugin with a Gradle platform plus a lightweight BOM property override mechanism. Applications can now override BOM-managed versions through standard Gradle constructs without pulling in the Spring DM plugin.
• Method-based TagLib syntax: PR #15465 introduces a method-based syntax for Grails tag libraries with full backward compatibility for the legacy closure-based form, plus benchmarks and updated documentation.
• Apache Maven Resolver in the shell CLI: The grails-shell-cli embeds Apache Maven 3.9.9 and Maven Resolver 1.9.22 for resolving plugin and dependency metadata in the legacy interactive shell. End-user Grails projects continue to build with Gradle - this only affects the shell CLI's own internal resolution.
• Grails Forge: The application generator at start.grails.org is the recommended way to scaffold a new Grails 8 application; it applies the correct BOM, enforcedPlatform semantics, and JDK enforcement rules automatically.
• Pre-tag release readiness: The new verify-branch.sh script (PR #15621) gives committers a one-command preflight check that the build is reproducible, signed, and publishable before a release tag is cut.
• Reproducible, byte-identical artifacts:PR #15625 makes per-module SBOMs and Groovydoc output byte-reproducible so that re-running a release produces identical bytes.

Performance and Runtime Behavior in Grails 8

For most applications, Grails 8 should look like a steady, incremental change in runtime behavior because Spring Boot 4 itself is not primarily a performance-focused release. A few specifics worth noting for capacity planning:

• Startup time is comparable to Grails 7 for a baseline Grails MVC application. Spring Boot 4 ships incremental startup improvements but no order-of-magnitude shift.
• Memory and footprint track Spring Boot 4's defaults. Embedded Tomcat remains the default; Undertow is temporarily unsupported in Grails 8 because it has not yet shipped Servlet 6.1 compatibility (the Grails Forge generator no longer offers Undertow as a selectable option).

Deprecations and Breaking Changes in Grails 8

As with any major release, Grails 8 removes functionality that has been deprecated across previous versions. These removals are intentional and aimed at keeping the framework maintainable over the long term. The official upgrade reference is the Grails 8 Upgrade Guide, which catalogs every change in detail.

Removed Long-Deprecated Features

The bulk of the deletions landed in PR #15565. The most consequential removals:

• Grails.web.JSONBuilder: Replaced by groovy.json.StreamingJsonBuilder. Code that constructs JSON manually with the old builder must move to the streaming builder.
• Legacy enum marshallers: The verbose EnumMarshaller for both JSON and XML is gone; SimpleEnumMarshaller is now always registered. Direct rendering of a single enum value via render(MyEnum.VALUE as JSON) now throws ConverterException (see PR #15212).
• Mixin annotation and AST transform: This includes MixinTargetAware and MixinTransformation. Use Groovy traits or extension modules instead.
• GORM legacy named queries: NamedCriteriaProxy, NamedQueriesBuilder, and the GORM AutoTimestamp annotation are removed. Use GORM where queries, finders, or @CompileStatic-friendly query DSLs instead.
• Plugin filtering hierarchy: CompatibilityPluginFilter, PluginFilter, BasePluginFilter, IncludingPluginFilter, ExcludingPluginFilter, IdentityPluginFilter, PluginFilterRetriever, and BinaryGrailsPluginDescriptor are all removed. Plugin discovery is now consolidated on the modern plugin manager.
• AetherGrapeEngine / AetherGrapeEngineFactory: the embedded Grape resolver in grails-shell-cli is removed. Maven dependency resolution in the shell now goes through Apache Maven Resolver directly.
• grails-events-compat: he Reactor 2 compatibility shim is gone. Applications that still imported reactor.bus.* shim classes must move to the modern grails-events API.
• Deprecated tag library methods: FormTagLib and ApplicationTagLib shed roughly a dozen long-deprecated methods. The full list is in the upgrade guide.

Behavior Changes to Be Aware Of in Grails 8

Even where APIs remain in place, several runtime defaults shift:

• @SpringBootTest no longer auto-configures MockMvc, WebClient, or TestRestTemplate. Tests that relied on the implicit injection must add @AutoConfigureMockMvc / @AutoConfigureWebClient / @AutoConfigureTestRestTemplate explicitly.
• @MockBean and @SpyBean are removed in favor of @MockitoBean and @MockitoSpyBean from org.springframework.test.context.bean.override.mockito. The new annotations work on test-class fields only and cannot be declared in @Configuration classes.
• TestRestTemplate moved to org.springframework.boot.resttestclient.
• HttpStatus.MOVED_TEMPORARILY is removed. Use HttpStatus.FOUND instead - both are HTTP 302 with no behavioral difference.
• Spring theme support is removed from Spring Framework 7. ThemeResolver, ThemeSource, Theme, SimpleTheme, and SessionThemeResolver no longer exist. Applications that switched stylesheets via Spring themes must implement the equivalent using configuration properties or session attributes.
• Spring Retry is no longer managed by Spring Boot 4. Applications that use @Retryable, @EnableRetry, or @Recover directly need to declare the dependency in build.gradle.
• Logback log files default to UTF-8. Log scraping pipelines that assumed the platform default charset must switch to UTF-8.
• Liveness and readiness probes are enabled by default on the Health endpoint; disable via management.endpoint.health.probes.enabled: false if needed.

Grails 8 Upgrade and Migration Considerations

Upgrading to Grails 8 is straightforward for teams that have kept up with deprecations, but it should still be approached deliberately. The upgrade is fundamentally a Spring Boot 3 to Spring Boot 4 migration with Grails-specific guardrails layered on top; the bulk of the breaking changes come from upstream platform shifts, not from Grails itself.

A Practical Migration Sequence for Upgrading to Grails 8

Follow these steps to simplify the migration from Grails 7 to Grails 8:

1. Upgrade to the latest Grails 7.x release first. Grails 7 finished the javax.* -> jakarta.* migration and moved Maven coordinates under org.apache.grails. Doing this on the latest 7.x release before jumping to 8 means each problem surfaces in isolation rather than all at once.
2. Address all deprecation warnings on Grails 7 before moving to Grails 8. Anything deprecated in 7 is removed in 8. The Spring Boot spring-boot-properties-migrator dependency is the single most useful tool here - add it as runtimeOnly, boot the app, fix every warning it logs, then remove the dependency.
3. Audit direct Spring imports. Search the codebase for org.springframework.orm.hibernate5.*, com.fasterxml.jackson.databind.*, org.springframework.boot.web.embedded.*, HttpStatus.MOVED_TEMPORARILY, and Theme-related classes. Each appears in the Grails 8 upgrade guide with the new replacement.
4. Validate plugins and custom framework extensions. Verify every Grails plugin in build.gradle has a Grails 8-compatible version. For grails-micronaut users, ensure the BOM is applied as enforcedPlatform (the Grails Gradle Plugin will fail the build at configuration time if it is not).
5. Update tests. Add @AutoConfigureMockMvc / @AutoConfigureTestRestTemplate where relevant, swap @MockBean for @MockitoBean, and update the TestRestTemplate import.
6. Plan your JDK story. JDK 21 is the baseline. If you use Micronaut anywhere, plan for JDK 25 in CI and production. Mixed-deployment teams should standardize before migration.
7. Test with production-like workloads. Spring Boot 4's defaults (UTF-8 logging, probes-on-by-default, devtools-livereload-off-by-default) are individually small but collectively visible in staging. Run a full pre-prod cycle.
8. Pay attention to startup time and redeploy behavior. Spring Boot 4 changes a number of dev-loop defaults (covered in the next section), and reload speed on medium-to-large applications becomes a measurable productivity factor during the migration itself.

Reloading Options for Grails 8 Development

Reload speed is the part of the developer feedback loop that gets noticeably worse as a Grails application grows, and Grails 8 is the right moment to make a deliberate choice rather than rely on the default. 

The Apache Grails development reloading documentation lists the supported options for Grails 8. The three that matter for most teams in practice are:

• Spring Boot Developer Tools is the default in newly generated Grails applications and the right starting point. It uses a dual-classloader approach to automatically restart the application context on code changes and supports live reload for static resources. The official Grails docs are direct about its scaling behavior: "This works well until your application becomes very large, at which point restarts may take longer or fail." On medium-to-large Grails applications, a DevTools restart routinely takes –seconds to minutes because every classpath change rebuilds the application context, drops in-memory state, evicts JIT optimizations, and re-runs @PostConstruct and bootstrap logic.
• IntelliJ IDEA Enhanced HotSwap in Debug Mode reloads modified classes during a debug session without restarting the application context. It avoids the full DevTools restart but is constrained by JVM hot swap's structural-change limits unless you also run on the JetBrains Runtime with -XX:+AllowEnhancedClassRedefinition. In practice, the perceived reload time on a medium-to-large application is tens of seconds, similar to DevTools because most non-trivial changes (adding a method, changing a Spring bean, modifying a GORM mapping) are exactly the structural changes the IDE cannot apply without a fuller reload.
• JRebel is a commercial JVM agent that performs true hot swapping via bytecode instrumentation, reloading classes, configurations, and resources without restarting the JVM and without losing application state. The reload is essentially instantaneous — typically well under a second, even on large applications - because nothing is being torn down and rebuilt. JRebel is the option Grails specifically recommends for advanced reloading needs, with first-class Grails / Spring Boot integration and a dedicated IntelliJ IDEA plugin.

Grails also lists Hotswap Agent and plain JVM debug-mode hot swap. Hotswap Agent is currently classified as experimental for Grails with documented limitations, and JVM debug-mode hot swap is limited to non-structural changes. Neither is a realistic primary reload story for an enterprise Grails 8 application, but both are viable for narrow use cases.

Spring Boot 4 itself flips one default that affects all of these: spring.devtools.livereload.enabled is now false by default. The Grails Forge generator opts back in via application-development.yml, but existing Grails 7 applications that rely on devtools live reload must add this configuration manually after the upgrade.

Why Choose JRebel for Medium-to-Large Grails 8 Applications?

The practical message for Grails 8 teams is simple. On a small application, DevTools is fine. As the application grows (and almost any application worth migrating to Grails 8 has grown) the per-change reload cost climbs from a few seconds to tens of seconds to, on the largest enterprise applications, minutes.

Multiply that by the number of changes a developer makes in a day and the difference between a tens-of-seconds reload and a sub-second JRebel reload is the difference between a productive day and a context-switching day.

JRebel matters most precisely where Grails 8 migrations have the biggest impact:

• Applications with significant in-memory state:caches, scheduled jobs, Spring Security sessions, GORM connection pools, queued messages, websocket connections. DevTools drops all of it on every reload; JRebel preserves it.
• Modular and multi-project Grails applications, where a one-line change in a shared module triggers a cascading rebuild across every consumer.
• Applications that use grails-micronaut, where the classpath is larger, the JDK requirement is higher (JDK 25+), and bootstrap is correspondingly heavier.
• Migration work itself, where you are iterating on Spring Boot 4 deprecation warnings, plugin compatibility fixes, and GSP/Groovy/Java changes in rapid succession. Every saved second of reload time compounds across the migration cycle.

For Grails 8 teams modernizing real production applications, the reload-speed gap between the free options and JRebel is large enough that it materially affects how long the migration takes — and how confident the team is when they ship it.

Final Thoughts on Grails 8

Grails 8 is about ensuring that Grails remains a first-class framework for building and running JVM applications in modern environments. The changes in this release reflect years of experience running Grails in production, the project's first full development cycle under the Apache Software Foundation, and a clear focus on the future of the ecosystem: Java 21, Spring Boot 4, Spring Framework 7, Hibernate 7, and Jakarta EE 10.

For teams already on Grails 7.x, the upgrade is incremental rather than disruptive, provided deprecation warnings have been kept clean. For teams still on Grails 6.x, the recommended upgrade path is to migrate to the latest Grails 7 release first, then to Grails . This work should be done before Spring Boot 3.5.x reaches end-of-life on June 30, 2026.

Teams that plan their upgrades thoughtfully will find Grails 8 to be a stable, capable platform for the next generation of Grails applications, and the first one explicitly designed to be stewarded by an open community for the long haul.

How to Get Involved in the Grails Project

Grails is built and sustained by its community. If you want to help shape the future of the framework, there are several ways to get involved. You can contribute code, documentation, or testing support, volunteer as a committer, help review issues and pull requests, or provide financial support to the project through the Apache Software Foundation. Every contribution, technical or otherwise, helps keep Grails healthy, sustainable, and moving forward.

• Apache Grails contribution guide
• Apache Grails issue tracker
• Apache Grails Users mailing list
• Apache Grails Dev mailing list
• Apache Grails Slack
• Friends of Apache Grails Open Collective
• Donate to the Apache Software Foundation
• Apache Grails 8 Upgrade Guide