Grails 8 raises the standard build and runtime baseline to Java 21 and uses Gradle 9.6.0. The standard Grails BOM remains on Groovy 5.0.7 and Spock 2.4-groovy-5.0, while Micronaut-enabled Grails applications use Micronaut-specific BOM variants that align with Micronaut 5 and require JDK 25 or later.

Grails 8 is built on Spring Boot 4.1.0 and Spring Framework 7.0.8. This brings the Spring Boot 4 modular artifact layout, Spring Framework 7 API removals, Jackson 3, Tomcat 11 and Jakarta Servlet 6.1, plus Spring Boot 4.1 dependency management for Spring Security 7.1, Spring Data 2026.0 and Micrometer 1.17.

The Grails 8 upgrade guide calls out the major application-impacting changes and links to the Spring Boot 4.0 migration guide, Spring Boot 4.1 release notes and Spring Framework 7.0 release notes.

Grails Forge can now generate applications configured for Grails Data with Hibernate 7. The create-* commands also accept a new -d, --data option (the previous -g and --gorm flags remain supported as legacy aliases) with the values hibernate5, hibernate7, and mongodb; the legacy value hibernate is still accepted and selects Hibernate 5:

Applications generated for Hibernate 7 consume grails-hibernate7-bom — or grails-hibernate7-micronaut-bom when combined with the grails-micronaut feature — consistently across the application dependencies, the buildscript classpath, and buildSrc. This avoids the dependency resolution conflicts that occur when an application generated for Hibernate 5 is manually switched to grails-data-hibernate7 while the default grails-bom remains on the build classpath. The database-migration feature also selects the matching grails-data-hibernate7-dbmigration plugin automatically.

Grails 8 unifies and retimes the plugin lifecycle so that the beans a plugin contributes are registered before Spring Boot processes its auto-configurations. A plugin bean now takes precedence over a Spring Boot default guarded by @ConditionalOnMissingBean — Boot backs off in favour of the plugin’s bean, with no need to override or remove it afterwards.

Plugins register beans through the new beanRegistrar() hook, which returns a Spring Framework BeanRegistrar. Because BeanRegistrar is a functional interface, a closure coerced with as BeanRegistrar is all that is required:

beanRegistrar() replaces the doWithSpring bean builder DSL, which is deprecated in Grails 8. The DSL continues to work for now, but you are strongly urged to migrate. See the upgrade guide for details.

Grails 8 continues the move toward method-based TagLib handlers while preserving compatibility with existing closure-based tags. Method-defined tags now bind named attributes more predictably, exclude inherited framework and Object methods from tag dispatch, and preserve real namespace property getters.

The Grails Gradle extension now defaults preserveParameterNames to true, so application Groovy compilation preserves method parameter names for features such as typed method TagLib arguments.

Tag library unit tests also clean up and rebuild TagLib metadata automatically between features. Tests that use TagLibUnitTest no longer need to manage purgeTagLibMetaClass, and specs that mock additional tag libraries continue to work across feature methods.

Links, form actions, pagination links, sortable column links, redirects, chains, and includes now resolve the target controller namespace automatically when namespace is omitted. In the normal case, where only one controller has the target name, controller and action are enough to generate the correct namespaced or non-namespaced URL. If multiple controllers share the same name, specify namespace to choose one explicitly. Use namespace="" in GSP markup, or namespace: null in Groovy code, to target a non-namespaced controller.

Controllers annotated with @GrailsCompileStatic can now invoke tag library methods without compile-time errors.

Both calling patterns are supported out of the box:

@GrailsCompileStatic recognises controllers and tag libraries by convention and marks tag dispatch points as permissible dynamic calls, while leaving the rest of the class fully type-checked.

Static compilation can now be enabled for every controller, service and tag library in an application from the nested compileStatic block of the grails build configuration, without annotating each class:

All three options are disabled by default and independent, or compileStatic { all = true } can be used as a shortcut to enable all of them. Any class that declares its own @CompileDynamic (or @GrailsCompileStatic/@CompileStatic/@GrailsTypeChecked/@TypeChecked) annotation keeps that setting, so the opt-in never overrides an explicit per-class choice. Tag libraries that still declare tags as closure fields (the deprecated form) are skipped automatically by the tagLibs opt-in — left dynamically compiled with a build warning — so define tags as methods to opt them in. See the GrailsCompileStatic section for details.

Integration tests that implement HttpClientSupport can now use httpPostForm(…​) to send application/x-www-form-urlencoded request bodies. The helper URL-encodes form fields using UTF-8, and repeated values in a Collection or array are encoded as repeated keys in insertion order.

The new grails-testing-support-latency module injects artificial latency into the application under test, so that requests randomly take longer. Slower responses widen the window in which timing bugs occur, turning intermittently flaky functional tests — assertions that race a navigation, missing waits, ordering assumptions — into deterministic failures. The module is inert until grails.testing.latency.enabled is set to true, and the delay range, the fraction of requests affected, and the url patterns are all configurable. See the Functional Testing section for details.

GORM for MongoDB can now declare a TTL index directly in the mapping DSL. Adding expireAfterSeconds to the indexAttributes of a single date-valued property creates a TTL index, and MongoDB automatically removes each document once it reaches the configured age:

A single property can likewise declare a $text index — or another special type such as 2dsphere — through indexAttributes: [type: 'text'].

When the options of an already-created index change between restarts, GORM now reconciles the difference instead of only logging a conflict. A changed TTL is applied in place with MongoDB’s collMod command — no drop, no rebuild — while any other option change is applied by declaring indexAttributes: [recreateOnConflict: true].

A new optional module, grails-data-mongodb-spring-data, lets an application use GORM for MongoDB and Spring Data MongoDB — its MongoTemplate and repositories — side by side over the same MongoClient, database and codecs, and, within a single @Transactional method, the same MongoDB transaction. When the module and spring-data-mongodb are on the classpath of a Spring Boot application that already has a GORM MongoDatastore, it auto-configures a MongoDatabaseFactory, a MongoTemplate and a primary transactionManager over GORM’s existing connection — GORM keeps ownership of the client:

The unified transaction shares GORM’s server-side ClientSession, so it requires GORM multi-document transactions to be enabled (grails.mongodb.transactional = true). Spring Data repositories are enabled the usual way with @EnableMongoRepositories, on a package separate from the GORM @Entity classes; only the connection, codecs and session are shared, and the two object-mapping models stay separate. See the Spring Data MongoDB Interoperability section of the GORM for MongoDB guide for details.

The historical grails shell CLI has been a core part of the Grails Framework since its inception, providing command-line tools for project creation, code generation, and application management. Nearly all historical references to the grails or grailsw commands pertain to grails shell functionality. The grails shell CLI relies on Profiles, consisting of skeleton directories and YAML-based configurations for application generation. However, this approach is less flexible than the feature-rich application generation capabilities of grails forge. The Grails Wrapper is a lightweight script (grailsw) and the accompanying JAR file is designed to bootstrap and load the CLI within a Grails Application. The grails shell CLI provides most of the same application generation functionality provided by grails forge. Importantly, it can also run scripts, such as run-app that call Gradle and/or your Grails Application. Most Grails plugins still include Grails Scripts that execute within grails shell CLI and have not yet been migrated to Gradle tasks. IntelliJ IDEA’s Grails plugin depends on grails shell for code generation and Grails command execution. Extending application generation in the grails shell CLI is straightforward: developers can create a Custom Profile and reference it as a Maven dependency, which is generally simpler than customizing grails forge.

In Grails 6.0.0, grails shell CLI was removed and replaced with grails forge CLI. However, in Grails 6.2.1, the grails shell CLI, along with Grails Profiles and the Wrapper were restored, empowering users to choose their preferred CLI and reclaiming functionalities that had not yet been fully transitioned to the grails forge CLI combined with Gradle tasks.

Certain grails shell CLI commands overlap with Gradle tasks.

For Gradle these use a variety of Gradle tasks provided by Gradle, Spring Boot, Grails or a Grails Plugin.

Partial list, for illustration purposes:

Additional details on these commands are covered in other sections of Grails documentation.

In Grails 6, grails forge was introduced to replace the application generation features of grails shell CLI, while forcing the transition of all other historical CLI functionality directly to Gradle tasks. This new CLI offers a superior architecture for application generation, particularly when incorporating multiple features, and starts and generates applications faster than the grails shell CLI. grails forge also powers start.grails.org and the "New Grails Project" feature in JetBrains' IntelliJ IDEA via the Grails Plugin. Unfortunately, in Grails 6, but corrected for 7, the grails forge CLI was invoked using the historical grails command, which confused users due to its markedly different feature set and architecture. The grails forge CLI is dedicated solely to initial application generation and the subsequent creation of components such as domains, controllers, services, interceptors, and tag libraries, which is all it can do. This CLI is entirely offline with precompiled templates and does not run or use Gradle or your Grails Application. With the grails forge CLI, the goal was to transition all other historical capabilities provided by the grails shell CLI to Gradle tasks. Although some advancements have been made in this transition, substantial work is still outstanding. The grails forge can be extended by forking the repository and hosting your own Grails Application Forge internally, which is generally more complex than extending grails shell with a custom profile.

For the reasons listed above, Grails 8 includes both CLIs and a combined delegating CLI that can invoke either CLI. grails-shell, grails-profiles, grails-wrapper and grails-forge projects are now all part of the grails-core project and are released together.

Grails 8 provides the following commands in any Grails install:

If Grails is working correctly you should now be able to type grails --version in the terminal window and see output similar to this:

If you want to set a context path for your application, create a configuration property in the "grails-app/conf/application.yml" file:

With this configuration, the application will be available at: http://localhost:8080/myapp/

Alternatively, you can also set the context path via the command line:

Alternatively, you can set the context path from the command line when using Gradle to run a Grails application. Here’s how you can do it:

Replace /your-context-path with the desired context path for your Grails application. This command sets the context path directly via the -Dgrails.server.servlet.context-path system property.

For example, if you want your application to be available at "http://localhost:8080/myapp," you can use the following command:

This allows you to configure the context path without modifying the application’s configuration files, making it a flexible and convenient option when running your Grails application with Gradle.

Grails 8 requires a minimum of Java 21 to both build and run Grails applications. This is an increase from Grails 7, which required Java 17. Update your project’s toolchain, CI pipelines, and deployment environments to use JDK 21 or later.

Grails 8 upgrades from Spring Boot 3.5.x to Spring Boot 4.1.x. This crosses the Spring Boot 4 major release boundary and adopts the Spring Boot 4.1 managed stack used by Grails 8: Spring Framework 7.0.x, Spring Security 7.1.x, Spring Data 2026.0.x, Micrometer 1.17.x, Jackson 3.1.x, Tomcat 11.0.x, and Jakarta Servlet 6.1. The upgrade includes the Spring Boot 4 module split, removed Spring Framework 6 deprecations, and additional Spring Boot 4.1 removals of APIs and properties that were deprecated in Spring Boot 4.0.

For full details, consult:

Spring Boot 4 split the monolithic spring-boot-autoconfigure module into domain-specific modules. Auto-configuration classes have moved to new packages. If your application imports or references auto-configuration classes directly, you will need to update those references.

Notable module changes:

For example, if your code imports MongoAutoConfiguration:

In addition to the auto-configuration class moves, two foundational interfaces were relocated out of nested packages and into org.springframework.boot directly:

The old locations are deprecated but retained for upgrade ease. If your application or plugin contributes an EnvironmentPostProcessor or BootstrapRegistryInitializer, update both the import and the corresponding META-INF/spring.factories key:

Spring Boot 4 renamed the MongoDB configuration property namespace for Spring Boot’s own auto-configuration. If your application.yml or application.groovy uses spring.data.mongodb. properties for Spring Boot auto-configuration, you must rename them to spring.mongodb.. Note that Grails GORM for MongoDB uses its own mongodb.* configuration namespace, which is unaffected by this change.

Spring Framework 7 removed the org.springframework.orm.hibernate5 package entirely. Grails 8 vendors these classes from Spring Framework 6.2.x into grails-data-hibernate5-spring-orm and grails-data-hibernate7-spring-orm so that both Hibernate 5 and Hibernate 7 users have a drop-in replacement.

This change is transparent for most applications since Grails manages the Hibernate integration internally. However, if your application directly imports any of the following classes, you must update your import statements based on which Hibernate version you are using.

Spring Framework 7 removed the deprecated HttpStatus.MOVED_TEMPORARILY constant. Use HttpStatus.FOUND instead - both represent HTTP 302 with no behavioral change.

If your application references HttpStatus.MOVED_TEMPORARILY directly (for example, in custom redirect logic or interceptors), update the reference:

As announced in the Grails 7.0.2 deprecation notice, the SimpleEnumMarshaller is now the default for JSON and XML enum serialization in Grails 8. Enums are serialized as simple string values (e.g., "SUBMIT") instead of the verbose legacy format with type metadata.

If you previously opted in via configuration, you can now remove it:

If you need to restore the legacy behavior temporarily, the deprecated marshallers remain available but will be removed in a future release.

Spring Boot 4 ships Jackson 3 (tools.jackson.*) and auto-configures a JsonMapper bean instead of the Jackson 2 ObjectMapper. Grails 8 follows that change: any Grails module that previously declared com.fasterxml.jackson.core:jackson-databind (Jackson 2) now declares tools.jackson.core:jackson-databind (Jackson 3.1.x via the Spring Boot 4.1 BOM).

What stayed the same:

What changed (and what you need to do if your code touches Jackson directly):

If you inject the auto-configured mapper: Spring Boot 4 provides a tools.jackson.databind.json.JsonMapper bean instead of com.fasterxml.jackson.databind.ObjectMapper. Update injection points to expect JsonMapper.

If you must stay on Jackson 2 temporarily: Spring Boot 4 still manages the Jackson 2 BOM and provides an opt-in toggle so the auto-configured mapper preserves Jackson 2 defaults:

This is intended as a migration aid only; new code should target Jackson 3.

Spring Boot Jackson helper class renames. If your code uses Spring Boot’s Jackson helpers, rename them to the Jackson 3 equivalents:

Configuration property renames. The spring.jackson.* namespace was reorganized. The spring-boot-properties-migrator (see the tip at the top of this guide) will detect most of these and warn at boot time:

Module auto-detection. Jackson 3 auto-detects all Jackson modules on the classpath by default. If you need to disable this — for example, to avoid an unwanted module being picked up — set:

Spring Framework 7 removed the theme infrastructure entirely. The following theme-specific classes and interfaces no longer exist:

If your application uses Spring theme resolution (for example, switching CSS stylesheets via ThemeResolver), you must replace this with your own implementation. This was deprecated in Spring Framework 6.0 and fully removed in 7.0.

GSP layouts and views that relied on theme resolution will need to use alternative approaches such as configuration properties or session-based preferences managed in application code.

Spring Boot 4 reorganized embedded server classes into separate modules. If your application or tests reference these classes directly, update the imports:

Applications using embedded Tomcat or Jetty should check for any direct class references and update accordingly. The spring-boot-tomcat module must now be an explicit dependency if you reference Tomcat classes directly.

Undertow is temporarily unsupported. Undertow has not yet been updated for Servlet 6.1, which Spring Boot 4 requires. As a result, Undertow is not an available embedded servlet container in Grails 8. Applications that previously used spring-boot-starter-undertow must switch to Tomcat or Jetty until Undertow ships Servlet 6.1 compatibility. The Grails Forge generator no longer offers Undertow as a selectable servlet implementation, and explicitly selecting it (for example, --servlet=undertow on the API/CLI) fails fast with IllegalArgumentException and a clear error message.

Spring Framework 7 removed the deprecated getLastModified method from the HandlerAdapter interface. If your application implements HandlerAdapter directly and overrides this method, remove the override. The framework no longer calls this method for Last-Modified header management.

Spring Boot 4 removed the SecurityProperties.DEFAULT_FILTER_ORDER constant. Spring Security is moving toward the fluent HttpSecurity configuration API for filter chain management, rather than explicit filter ordering via constants.

If your application references DEFAULT_FILTER_ORDER for custom filter positioning, replace it with the concrete value -100 (computed as OrderedFilter.REQUEST_WRAPPER_FILTER_MAX_ORDER - 100). Longer term, consider migrating to the fluent HttpSecurity API for filter chain configuration.

Grails 8 standardizes on Gradle’s native platform() dependency management and no longer applies the io.spring.dependency-management plugin. The Grails Gradle Plugin now adds grails-bom as a Gradle platform() on every declarable project configuration, and a new bundled plugin (org.apache.grails.gradle.bom-property-overrides, applied automatically by the Grails Gradle Plugin) preserves the property-based version-override workflow that Spring DM provided.

No action is required for most applications. The standard gradle.properties and ext['…'] override forms continue to work exactly as before:

The grails { springDependencyManagement = … } flag on GrailsExtension is deprecated. For backward compatibility, setting it to false is still honored and is equivalent to grails { bom = null }: it suppresses the automatic Grails BOM platform() application, just as it previously prevented the Spring Dependency Management BOM from being applied. New builds should use grails { bom = null } instead.

Two Spring DM features have no automatic migration. If your build.gradle uses either of the patterns below, update it as follows:

Behavioural difference to be aware of: conflict resolution. The BOM’s default managed versions are applied via a regular Gradle platform(), which participates in standard conflict resolution (highest-version-wins). A transitive dependency can therefore pull a non-overridden managed version higher than the BOM default. If you require Spring DM’s "BOM wins always" behaviour for the default managed versions, declare enforcedPlatform("org.apache.grails:grails-bom:$grailsVersion") instead of relying on the auto-applied non-enforced platform.

An explicit property override (ext['…'] or gradle.properties) is applied as a strict constraint and always wins - including when it downgrades a version - so overrides behave as they did under Spring DM. Overriding a property that selects an imported BOM’s version (for example spring-boot.version) re-imports that BOM at the overridden version and applies its updated managed set.

Selecting or opting out of the auto-applied BOM. The Grails Gradle plugin applies a single Grails BOM automatically, selected by the grails.bom property. Its value is the BOM artifact name within the org.apache.grails group, which the plugin resolves as org.apache.grails:$bom:$grailsVersion. It defaults to grails-bom, which preserves the Grails 7 behaviour and is the right choice for the vast majority of applications. Exactly one Grails BOM is ever applied; the BOMs are split by integration (default / hibernate5 / micronaut), so the plugin never layers two of them.

Select a different curated variant when your application needs it - for example the Micronaut variant, which the plugin applies as an enforcedPlatform:

Set it to null to suppress the automatic BOM application entirely - for example when you intentionally want to manage Grails dependency versions yourself (consuming Grails modules from a different curated platform):

When set to null, the Grails Gradle plugin will not declare a Grails platform()/enforcedPlatform() on your configurations and will not apply the org.apache.grails.gradle.bom-property-overrides plugin. You are responsible for declaring the BOM yourself and, if you still want gradle.properties / ext['…​'] overrides, applying id 'org.apache.grails.gradle.bom-property-overrides' explicitly.

Spring Boot 4 renamed several starters as part of its modularization effort. If your build.gradle references any of the following, update the artifact id:

For WAR deployment to an external Servlet container, Spring Boot 4 introduced a dedicated spring-boot-starter-tomcat-runtime artifact that contributes only the integration classes needed to start under an external container, without bundling the embedded Tomcat distribution into the WAR.

Replace the previous "change scope to provided/`testImplementation`" idiom with the new starter:

The Grails deployment guides have been updated to reflect this idiom. Embedded Tomcat usage (the default for grails run-app and bootable WARs) continues to use spring-boot-starter-tomcat unchanged.

Spring Boot 4 made several breaking changes to its test infrastructure. Most Grails tests use GrailsUnitTest, GrailsWebUnitTest, and Integration and are unaffected, but if your application uses @SpringBootTest directly the following apply.

@SpringBootTest no longer auto-configures MockMvc, WebClient, or TestRestTemplate. Add the corresponding @AutoConfigureMockMvc / @AutoConfigureWebClient / @AutoConfigureTestRestTemplate annotations to opt in.

@MockBean and @SpyBean were removed. Replace them with @MockitoBean and @MockitoSpyBean from org.springframework.test.context.bean.override.mockito. The new annotations work as fields in test classes only — they cannot be declared in @Configuration classes.

MockitoTestExecutionListener was removed. If your test infrastructure registers it explicitly, remove the registration; Spring’s bean override support handles @MockitoBean directly.

TestRestTemplate package change. TestRestTemplate moved to org.springframework.boot.resttestclient. Update the import. A new RestTestClient and corresponding @AutoConfigureRestTestClient annotation are also available as a fluent alternative.

Spring Boot 4 changed the default of spring.devtools.livereload.enabled from true to false. If you rely on browser live reload during development, opt in explicitly under the development environment so non-development environments still honor the new Spring Boot 4 default:

Spring Boot 4 removed spring-retry from its managed dependencies. Spring for Apache Kafka and Spring AMQP have moved off Spring Retry to Spring Framework’s new retry support; if you used Spring Retry transitively through those projects you may not need it any more.

If your application directly uses @Retryable, @EnableRetry, or @Recover, declare the dependency explicitly in build.gradle:

Spring Boot 4.0 and 4.1 made several smaller default-behavior changes that you may notice but rarely require code changes:

Grails 8 removes the purgeTagLibMetaClass test hook used by some web and TagLib unit tests. TagLib metaclass cleanup now happens automatically as part of the web test infrastructure, so test specs should delete any custom purgeTagLibMetaClass property or getter.

If your tests use TagLibUnitTest and mock additional tag libraries with mockTagLib(…​) or mockTagLibs(…​), those mocked tag libraries are rebuilt automatically between feature methods. No replacement flag is required.

Grails 8 introduces method-based tag handler syntax as the recommended way to define tags. Closure-based handlers are still supported for backward compatibility.

Method tags with the conventional signatures def tag(Map attrs), def tag(Closure body), and def tag(Map attrs, Closure body) are discovered automatically. Zero-argument method tags and method tags that bind named attributes directly to method parameters must use @grails.gsp.Tag; this avoids exposing ordinary public helper methods as tags.

Grails Gradle application builds preserve Java and Groovy method parameter names by default (see §22.3 below). If you compile TagLib classes outside those plugins, enable Java -parameters and Groovy groovyOptions.parameters = true so @Tag methods can bind attributes by parameter name.

To exclude a conventional public method from being exposed as a tag (for example, a helper that must remain public to satisfy an interface), annotate it with @grails.gsp.NotATag:

The compile-time deprecation warning emitted for closure-based tag fields can be silenced by setting the system property grails.taglib.warnDeprecatedClosures=false.

Some third-party plugins have not yet been updated for Spring Boot 4 / Spring Framework 7 compatibility. The following are known blockers at this time:

Check the Grails issue tracker for the latest status of plugin compatibility.

JSON views now use Groovy’s groovy.json.JsonGenerator implementation instead of the previous Grails-specific JSON generator infrastructure. If you previously customized JSON view rendering with Grails-specific generator classes, migrate that logic to a groovy.json.JsonGenerator.Converter implementation.

This change applies to JSON views rendered by the grails-views-gson module. The grails.converters.JSON.registerObjectMarshaller(…​) API is still used by the grails-converters module for render …​ as JSON and related converter-based rendering.

To migrate your custom converters:

It is no longer possible to render a single enum value as JSON using the render(Number.ONE as JSON) syntax. Previously, rendering an enum value would produce a JSON string with the type and name of the enum value like:

Rendering an enum value as JSON will now instead throw a ConverterException. See PR 15212 for more details on this change.

Grails 8 supports both Hibernate 5 (the default) and Hibernate 7. If you are upgrading from Grails 7 and also want to migrate from Hibernate 5 to Hibernate 7, apply the grails-hibernate7-bom and the Hibernate 7 plugin in addition to the standard Grails 8 upgrade steps.

The following sections cover every breaking change introduced between Hibernate ORM 5.6.x (used by Grails 7) and Hibernate ORM 7.0.x, and what you need to do in your Grails application.

Grails 8 changes the validation default so that an unconstrained persistent (domain) property is nullable by default rather than required. This aligns Grails with the rest of the JVM persistence/validation ecosystem (JPA/Hibernate, Spring Data, Micronaut Data and Jakarta Bean Validation), all of which treat an unconstrained property as valid when null.

Previously every domain property without an explicit constraint had an implicit nullable: false applied, so save() failed validation when the property was null. From Grails 8 such a property is optional unless you declare otherwise:

This is a validation-layer change only. Column/DDL nullability is governed separately by the mapping layer and is unaffected. Command objects are also unaffected: Validateable command-object fields remain required by default.

To restore the legacy required-by-default behaviour for an entire application, set the new grails.gorm.default.nullable property to false:

The existing grails.gorm.default.constraints wildcard form also works:

Grails 8 upgrades from Apache Groovy 4 to Apache Groovy 5. Most applications need no changes, but a few stricter behaviors can affect application code.

Grails 8 ships the full set of supported MIME types as built-in framework defaults. Previously every newly generated application declared a grails.mime.types block in grails-app/conf/application.yml; the Grails Forge and the application profiles no longer generate that block, because the framework now supplies the same defaults out of the box.

The built-in defaults cover all, atom, css, csv, form, html, js, json, multipartForm, pdf, rss, text, hal and xml, the same set new applications historically declared.

No action is required. A declared grails.mime.types still replaces the defaults, exactly as in Grails 7. Your existing block remains authoritative and you get precisely the types you declared (including a deliberately narrowed set). New applications simply no longer need the block, because the framework supplies these defaults when none is configured.

Optional: merge instead of replace. If you would rather add to the defaults than re-declare them, set grails.mime.mergeDefaults to true. Your declared entries are then merged over the built-in defaults. An entry replaces the default for its extension, and any extension you do not declare keeps its default, so you can register a single custom type without restating the full list:

Grails 8 honors the HTTP Accept header for content negotiation for every client by default, including browsers.

In Grails 7 and earlier, the Accept header was ignored for the major browser rendering engines: grails.mime.disable.accept.header.userAgents defaulted to ['Gecko', 'WebKit', 'Presto', 'Trident']. That was a workaround for very old browsers (Firefox 2 and 3) whose Accept header ranked XML above HTML. Modern browsers send a well-formed header that already prioritizes HTML (text/html at q=1.0, application/xml at q=0.9), so the workaround is no longer needed.

The practical effect of the old default was that a browser-issued fetch() or XMLHttpRequest call requesting application/json would receive HTML instead of JSON, because those calls do not send an X-Requested-With: XMLHttpRequest header (only libraries such as jQuery add it automatically). In Grails 8 such a request correctly receives JSON.

What changed: grails.mime.disable.accept.header.userAgents now defaults to unset, so no user agents are filtered.

Most applications need no action. Browser page loads still resolve to HTML because modern browsers rank text/html highest, and withFormat { html { } json { } } continues to serve HTML to browsers and JSON to clients that ask for it.

respond endpoints without an HTML view now error for browser requests. Because browsers now negotiate text/html, an action that uses respond(…​) but has no corresponding HTML view (GSP) can no longer return JSON to a browser by accident. It negotiates html and attempts to render the missing view, which results in an error. Previously the browser’s Accept header was ignored, so such an endpoint happened to return JSON. If you have browser-facing respond endpoints, add an HTML view for the action (or render an appropriate response directly). API clients that send a specific Accept such as application/json are unaffected.

To restore the Grails 7 behavior of ignoring the Accept header for browsers, set the property explicitly:

In earlier versions, Grails added Spring’s @EnableWebMvc annotation to the generated Application class at compile time. @EnableWebMvc is a Spring Framework configuration annotation that is not intended to be combined with Spring Boot: it imports DelegatingWebMvcConfiguration, which eagerly registers a fixed set of MVC beans and switches off Spring Boot’s WebMvcAutoConfiguration. In a Boot application this produced bean-definition override warnings at startup (for example for localeResolver and internalAutoProxyCreator) and prevented Boot’s conditional, more configurable auto-configuration from taking effect.

Grails 8 removes the auto-injected @EnableWebMvc. Spring Boot’s WebMvcAutoConfiguration is now active for Grails servlet web applications, which is the intended Boot behavior and resolves those override warnings.

No action is required for most applications. Grails adapts internally so the change is transparent. The notes below explain the behavioral differences this introduces and the configuration toggles available if you need to control them.

Several Grails framework beans that were previously registered unconditionally are now guarded with @ConditionalOnMissingBean, so a bean of the same name (or type) defined in an application configuration class (a @Bean method) takes precedence cleanly instead of relying on bean-definition overriding:

No action is required. The framework beans still register by default; this only changes what happens when you define your own. Previously, defining one of these beans produced a bean-definition override (with a startup warning, or a failure when spring.main.allow-bean-definition-overriding is false). Now the framework bean simply backs off.

In Grails 7 and earlier, the beans a plugin contributed through doWithSpring were registered after Spring Boot had processed its auto-configurations. A plugin that wanted to replace a Boot-provided bean therefore had to rely on bean-definition overriding, and Boot beans guarded by @ConditionalOnMissingBean never saw the plugin’s bean in time to back off.

In Grails 8 the plugin lifecycle is unified and retimed: plugin bean definitions — both doWithSpring and the new beanRegistrar() hook — are drained into the bean definition registry before Spring Boot expands its auto-configurations. The practical effects are:

The bean builder DSL is deprecated. doWithSpring() on GrailsApplicationLifeCycle and grails.plugins.Plugin is deprecated as of Grails 8 — it continues to work, but the recommended way to register beans is the new beanRegistrar() hook, which returns a Spring Framework org.springframework.beans.factory.BeanRegistrar.

Before (deprecated bean builder DSL):

After (Spring BeanRegistrar). BeanRegistrar is a functional interface, so a closure coerced with as BeanRegistrar is all that is required — a separate class is optional and only worth it for more involved or reusable registration:

Both hooks may be used on the same plugin during migration; when a registrar and the DSL register a bean under the same name, the registrar’s definition wins.

Bean-definition overriding edge case. Grails defaults spring.main.allow-bean-definition-overriding to true, and under that default nothing changes: an application bean (from the application class, resources.groovy or resources.xml) that uses the same name as a plugin bean still replaces the plugin’s bean. However, because plugin beans now register earlier and application beans register in a separate, later step, an application that explicitly sets spring.main.allow-bean-definition-overriding to false will see a BeanDefinitionOverrideException for an application bean that shadows a plugin bean — in previous releases the two definitions were merged before a single registry write, so the shadowing was silent even with overriding disabled.

Most applications and plugins need no action. Behavior only changes where a plugin bean and a conditional Boot bean competed for the same name or type — the plugin bean now wins, which is almost always the intended outcome.

Grails 7.2 upgrades the SiteMesh 3 integration to a filter-less architecture. Decoration is now performed by a Spring MVC ViewResolver rather than a Servlet filter. This change improves performance, eliminates ordering issues with other filters, and correctly supports async controller return types (Callable, @Async).

Starting from Grails 7, Java 17 serves as the baseline requirement for the framework, matching Spring Framework and Spring Boot’s minimum Java version. When upgrading to Grails 7, ensure that your project is configured to use Java 17. Updating to Java 17 allows you to take advantage of the latest features, security enhancements, and performance improvements provided by Java 17.

Please make sure to update your project’s Java version to 17 before proceeding with the Grails 7 upgrade. Doing so will ensure a seamless transition to the latest version of Grails and enable you to enjoy all the benefits that Java 17 has to offer.

Grails 7.0.x adopts Groovy 4.0.30 as it’s baseline requirement. Several changes in Groovy 4 can affect your application. Changes that may affect a Grails Application or Plugin include:

To re-enable invokedynamic, use the grails extension in your build.gradle:

Grails 7 moved to a mono repository. As part of this move, all projects that make up a grails release now have a common version. Setting grailsVersion in gradle.properties is the proper way to specify a set of dependencies that are compatible with each other for a given Grails release. Please remove older properties such as gormVersion & grailsGradlePluginVersion and exclusively use this property going forward.

Previously Grails did not have a single Bill of Materials (BOM). Instead it had a micronaut-bom and a spring-bom that existed side by side. As of Grails 7, a grails-bom is published that inherits from the spring-bom and the micronaut-bom is not included by default.

Grails 7 introduces a BOM that includes all the dependencies required for a Grails application. This BOM is available in the org.apache.grails:grails-bom artifact. The BOM is automatically applied when a Grails Gradle plugin is applied via the Spring Dependency Management plugin. For projects that do not use a Grails Gradle plugin, you can apply the BOM via a Gradle Platform:

Because all Grails projects will apply the Grails Gradle plugin, the BOM is automatically applied. You can override a version in the BOM by setting the associated Gradle property. The possible gradle properties are generated as part of this documentation. Please see link:../ref/Versions/Grails BOM.html[Grails BOM Dependencies] for a quick reference.

Grails has transitioned to the Apache Software Foundation (ASF). As a result, the group ID for Grails artifacts has changed to org.apache.grails. This change applies to all Grails packages, including core plugins and core dependencies, maintained by the Grails team. When upgrading to Grails 7, ensure that you update your build configuration to use the new group ID.

There is a RENAME.md in the grails-core repository that maps previous coordinate names to new names. Additionally, there is a script to aid in the updating of Grails projects to the new coordinates. The script is located in the etc/bin directory of the grails-core repository and can be run as follows:

This script will scan any gradle file and attempt to update both exclusions & dependencies to the new coordinates.

One of the major changes in Grails 7 is the modernization of it’s build system. As a side effect of this modernization, the Grails build is fully parallel & lazy. Moreover, most tasks have been enhanced to be cacheable. When updating to Grails 8.0.0-M3, there may be required updates to various tasks we distribute since the inputs of those tasks have changed to support lazy configuration.

The ASF strongly encourages reproducible builds as part of it’s security requirements. We have begun making the Grails build reproducible - that is, if you build with the same settings as the GitHub action the produced artifacts should be identical. We have starting addressing reproducible builds under the ticket #14679.

A side effect of making our builds reproducible is that Grails applications can also now be reproducible. The benefits of reproducible builds are well documented, but for Grails applications, some of the side effects include:

To make your local build reproducible, you’ll want to set the environment variable SOURCE_DATE_EPOCH to a fixed date. For Grails, we set this value to the last commit in git via the bash command: SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)

Grails 7.0.x is built on the Spring Framework, version 6.2.x. If your project uses Spring-specific features, refer to the Upgrading to Spring 6 guide.

This update introduces enhancements and fixes to the Spring Framework, providing you with the latest improvements in dependency injection, web frameworks, and other Spring-related functionalities.

Grails 6 used Spring Boot 2.7.x. Grails 7.0.x updates this to Spring Boot 3.5.x. For more information, consult the release notes for previous Spring Boot releases: 1. Spring Boot 3.5 Release Notes 2. Spring Boot 3.4 Release Notes 3. Spring Boot 3.3 Release Notes 4. Spring Boot 3.2 Release Notes 5. Spring Boot 3.1 Release Notes 6. Spring Boot 3.0 Release Notes

In addition to the coordinate changes, the version updates, and the build updates, to upgrade your project it is advised to use an application generator and compare it to your existing project. The preferred app generator for Grails is start.grails.org. Please note that several previously required gradle configurations have been integrated into the Grails Gradle Plugins as defaults. Compare a freshly generated application to your application and apply any associated changes.

Both the legacy grails-shell-cli and grails-forge-cli are now included with Grails 7. Please see the Downloading & Installing section of this guide for important background on how to use the Grails CLI commands.

Grails 7 introduces several breaking changes that may require updates to your application.