Java开发提效 | Grails 8 企业级平稳迁移指南（附 JRebel 免费试用申请通道）
作为Apache Grails从Apache软件基金会（ASF）的顶级项目（TLP）毕业后的首个主要版本，Grails 8标志着该框架全面转型为基于Java 21/25和Spring Boot 4的现代化技术栈。然而，企业在享受这些强大新功能带来的好处的同时，也面临着现实工程中的挑战：在大规模代码库中，应用程序重新加载速度变慢，开发效率下降。
作为 JRebel 官方授权合作伙伴，龙智为您带来Apache Grails 副总裁兼主席 James Fredley 对Grails 8 的前沿特性解读，以及平稳升级指南，更针对中大型项目的研发痛点，提供行业级热部署能效优化方案，助力 Java 团队扫清升级路上的效率障碍。
Grails 8标志着Grails框架演进的又一重要里程碑。该版本重点聚焦于长期稳定性、生态系统兼容性，以及对 Grails 应用在生产环境中所依赖的基础架构进行现代化改造。
作为 Apache Grails 的副总裁兼主席，我一直带领团队进行 Grails 8 的研发工作。继续阅读，深入了解 Grails 近期转型为 Apache 软件基金会（ASF）项目的幕后故事，看看 Grails 8 带来了哪些新特性，为何做出这些改变，以及 Java 开发团队在准备采用 Grails 8 时应做哪些考量。
此外，我还将介绍发布时间线、主要平台变更、废弃特性，以及将现有 Grails 应用升级到 Grails 8 的实用指南。
新篇章：Grails 正式入驻 Apache 软件基金会
2025 年 9 月，历经 18 个月的迁移努力，Apache Grails正式从孵化项目毕业，晋升为 Apache 软件基金会（ASF）顶级项目（Top-Level Project, TLP）。对于一个自 2005 年起持续迭代至今的框架而言，这是其发展史上最具里程碑意义的治理变革，这重新奠定了未来所有Grails版本（包括Grails 8）开发的基础。
在 Apache 软件基金会框架下治理、开发与发布 Grails
入驻 ASF 改变了 Grails 的治理、开发与发布方式。所有权从单一组织主导模式（Grails 曾先后由 G2One、SpringSource、Object Computing 以及 Grails 基金会/Unity 基金会轮流托管）转变为志愿者驱动、厂商中立的项目管理委员会，并在强调共识与透明的“Apache 之道”指导下运作。
如今的决策均在公开邮件列表中讨论，代码审查完全开放，发布流程严格遵循 ASF 关于许可合规、来源追溯与构建可重复性的政策要求。对于企业团队而言，这意味着更清晰的文档记录、可预测的治理机制以及不存在单一的企业故障点。
此次转型背后的技术工作量相当庞大。
变更内容包括：
GitHub 仓库整合：Grails 团队将 24 个以上的独立 GitHub 代码库整合为一个 grails-core 单体代码库（mono-repo）。该仓库现包含 109 个 Gradle 项目，并生成超过 325 个已发布的 JAR 文件。
构建时间大幅缩短：Grails 版本的构建时间从原来的三周缩短至约 30 分钟。
统一的 Maven 坐标：Maven 坐标已统一为org.apache.grails；每个发布的构件均经过许可证合规性审查，并为每个 JAR 文件自动生成软件物料清单（SBOM）。构建系统本身已实现端到端可重复性，任何第三方均可独立验证发布内容。这一能力不仅惠及框架本身，也为下游 Grails 应用带来益处。
重焕活力的 Grails 社区
同样重要的是，入驻 ASF 显著激发了社区活力。Grails 7是首个在 ASF 框架下发布的稳定版本，其开发团队成员构成远比以往版本更为广泛——其中不乏对Apache Groovy本身做出重要贡献的开发者。随之而来的是新提交者的不断加入、全新邮件列表的启用、焕然一新的 Slack 工作区，以及更加活跃的问题跟踪系统。
这一转变对框架的长期采用具有直接影响：仅依赖单一维护者的框架是脆弱的，而依托成熟基金会、拥有数十位活跃贡献者的框架则具备韧性。因此，在审视 Grails 8 发布时，必须将其置于这一重焕动能的社区背景之下来考量。
Grails 重焕发展新动能
Grails 8 是首个完全在 ASF 管理下规划并执行的主要版本，体现了项目对其新运营模式的信心。其发展路线图不再受限于单一组织所能提供的资金支持，而是由更广泛的 JVM 生态系统的发展趋势，以及志愿者团队所具备的引领能力来共同决定的。
回顾 Grails 7：承前启后的关键一步
理解 Grails 8 的演进方向，首先需要回顾 Grails 7 已交付的成果。Grails 7.0.0 于 2025 年 10 月 18 日发布，是 ASF 接管后首个稳定版本，它为 Grails 8 的所有上层构建奠定了技术基础。
通过 Grails 7 实现 Java 现代化
Grails 7 实现了整个技术栈的现代化升级。它全面迁移至 Apache Groovy 4.0.x、Spring Boot 3.5.x、Spring Framework 6.2.x 以及 Jakarta EE 10（即期待已久的`javax.* 到 jakarta.* 的命名空间迁移），并将最低运行环境要求提升至 Java 17。Maven 坐标统一调整为 org.apache.grails；grails-i18n 插件被迁移至独立的坐标空间，并默认设置为可传递；整个构建过程实现了逐字节级别的完全可重复，且为每个 JAR 文件生成了 SBOM（软件物料清单）。Grails Forge 应用程序生成器（start.grails.org）以及轻量级的 Grails Wrapper（grailsw，约 25KB）作为核心命令行工具（CLI），与传统的 Shell 脚本一同发布。功能测试方面迎来了全面焕新，引入了 Geb 8 及容器化浏览器支持，同时，cloud.wondrify.asset-pipeline 5.x 取代了旧版的 Asset Pipeline 坐标。
Grails 7 还完成了那些不引人注目但不可或缺的代码精简工作。它为模块化应用添加了多项目重载支持，并且将一长串来自 Grails 5 和 6 时代的已废弃 API 要么直接移除，要么安排在 Grails 8 中移除。换句话说，Grails 7 在其整个发布周期内，致力于使框架与现代 JVM 接轨，推动项目满足 ASF 的政策合规要求，并清理好跑道。而 Grails 8，正是团队在跑道清理完毕、畅通无阻的情况下所构建的成果。
Grails 8 发布计划与演进策略
Grails 8 的开发始终围绕一个清晰目标：使框架与现代 JVM 生态系统对齐，同时为企业级 Grails 应用提供稳定且面向未来的基石。其发布节奏也体现了这一优先级，在必要的平台升级与可预期的迁移路径之间取得平衡。
Grails 8 发布窗口
Grails 8 的开发工作于 2025 年 11 月下旬正式启动，紧随 Spring Boot 4.0.0 正式版（GA ）发布之后。首个公开里程碑版本Grails 8.0.0-M1 于 2026 年 5 月 6 日发布，后续里程碑版本、候选发布版（RC）及最终的 8.0.0 正式版（GA）的发布节奏，将紧密跟随底层平台栈（如 Spring Boot、Groovy 等）的成熟度。在 8.0.0 正式版（GA ）正式发布之前，建议团队将 8.0.x 里程碑版本视为预览构建，仅用于技术评估与迁移规划，而非用于生产环境部署。
平台对齐驱动 Grails 8 的发布节奏
Grails 8 有意与 Spring Boot 4.0 和 Spring Framework 7.0 紧密绑定。这正是 M1 版本未能更早发布的原因：框架不会基于尚未正式发布的 Spring 技术栈推出主要版本。一旦 8.0.0 正式版（GA）正式发布，该项目计划按照Spring Boot自身的月度更新周期，保持每月发布一次8.0.x版本补丁的频率，并针对安全问题和紧急修复提供非正式版本更新。
Grails 7 与 Grails 8 的生命周期重叠
7.0.x 版本线将持续获得全面的更新与维护，直至 Spring Boot 3.5.x 于 2026 年 6 月 30 日终止生命周期。这为团队提供了一条清晰的过渡路径：在 Spring Boot 3.5 获得官方支持期间，团队可以继续安心使用 Grails 7，并利用这段窗口期规划向 Grails 8 的迁移，从而避免陷入在不再受支持的底层平台上运行的困境。Grails 6.2.3（于 2025 年 1 月 3 日发布）是 6.2.x 系列的最终版本，也是迁入 ASF 前的最后一个版本；目前仍在使用 Grails 6 的团队应规划先迁移至 7.0.x，再升级至 8.0.x，而非尝试一步跨级跃升。
Grails 8 背后的设计目标
每个主要的 Grails 版本都由少数几个核心目标驱动。对于 Grails 8 而言，这些目标聚焦于长期生命力、代码清晰性以及互操作性。
● 长期生命力
Grails 8 使框架与具备多年支持周期的平台保持对齐，包括 Java 21 LTS、Spring Boot 4.0.x、Jakarta EE 10 以及 Hibernate 7。通过紧跟核心依赖的长期支持分支（并移除那些将框架绑定在这些依赖旧版本上的类与 API），Grails 8 能够顺畅地接收安全与功能更新，而无需进行破坏性的代码重写。在入驻 ASF 期间引入的单体代码库（mono-repo）、可重复构建以及 SBOM（软件物料清单），进一步减轻了维护负担，从而确保项目能够维持这一发布节奏。
● 代码清晰性
Grails 8 删除了大量遗留代码——包括初代 JSONBuilder、Mixin AST 转换、已废弃的 EnumMarshaller 类、旧版命名查询基础设施（NamedCriteriaProxy,NamedQueriesBuilder）,AetherGrapeEngine,已废弃的插件过滤器，以及多个早已废弃的 MongoEntity 和标签库方法。其结果是，公共接口更小、更专注，且推荐的做法也是唯一的方式。这一改变使得 Grails 框架更易于学习，也更易于维护和支持。
● 互操作性
Spring Boot 4 已将其自动配置拆分为领域专用模块（如 spring-boot-webmvc,spring-boot-servlet,
spring-boot-mongodb 等）,Spring Framework7 移除了自身的org.springframework.orm.hibernate
5 包，并采用了 JSpecify 可空性注解,同时 Jackson 3 取代 Jackson 2 成为默认的 JSON 映射器。Grails 8 全面吸收了这些上游变更，从而确保在 Grails 应用中直接调用 Spring 或 Jakarta API 的团队，能够无缝使用这些现代且受支持的版本，而无需与Grails进行技术对抗。
Grails 8 与现代 JVM 及 Jakarta 标准的对齐
Grails 8 明确与当前一代 JVM 生态及 Jakarta 标准保持同步。
| 组件 | Grails 7 | Grails 8 |
|---|---|---|
|
Java 基线版本 |
17 |
21 |
|
Spring Boot（Spring 启动器） |
3.5.x |
4.0.x（M1 版本中为 4.0.5） |
|
Spring Framework（Spring 核心框架） |
6.2.x |
7.0.x（M1 版本中为 7.0.6） |
|
Jakarta EE（企业版 Java 规范） |
10 |
10 |
|
Jakarta Servlet API（Servlet 接口规范） |
6.0.x |
6.1.0 |
|
Hibernate ORM（对象关系映射框架） |
5.6.x |
M1 版本中为 5.6.x，后续里程碑版本将升级至 7.x |
|
Apache Groovy（动态语言运行时） |
4.0.x |
M1 版本中为 4.0.x |
|
Gradle（构建自动化工具） |
8.14.x |
9.4.1 |
|
Jackson（JSON 数据处理库） |
2.x |
3.x（包名变更为 tools.jackson.*） |
|
Spock（测试与规范框架） |
2.3-groovy-4.0 |
2.3-groovy-4.0（Micronaut 配置文件中已支持 2.4-groovy-5.0） |
↑ Grails 7 与 Grails 8 的 JVM 及 Jakarta 要求对比
Hibernate 7 的升级正在通过 PR #15568 推进合并，这是一项基于 8.0.x-hibernate7 分支的大量工作，取代了之前在 PR #15530 中的尝试。预计它将在 8.0.0 GA 发布前完成合并，这也是为什么应将 M1 视为平台转型的预览，而非最终形态。
这种对齐是必要的，因为 Spring Framework 7 和 Spring Boot 4 都是围绕 Java 17+、Jakarta Servlet 6.1 以及全新的模块化自动配置布局而设计的。如果停留在旧的技术栈上，将迫使 Grails 无限期地向后移植（backport）安全修复；相反，该框架与其底层基础同步演进。
通过 Grails 8 减少历史遗留负担
Grails 8 的开发工作中，有相当大一部分是做减法。通过 PR #15565，以下内容已被正式移除：
旧版 JSON/XML EnumMarshaller
JSONBuilder（已被StreamingJsonBuilder取代）
旧的 Mixin/ MixinTargetAware/MixinTransfor
mation机制已弃用的 ConstraintsEvaluator
CompatibilityPluginFilter 及整个 PluginFilter 层级结构
BinaryGrailsPluginDescriptor
CorePluginFinder（核心插件查找器）
AetherGrapeEngine 与 AetherGrapeEngineFactory
原始的 gson-views JSON 生成器类
GORM AutoTimestamp 注解以及 NamedCriteriaProxy/NamedQueriesBuilder 命名查询基础设施（仅其测试类就超过 1,000 行代码）
grails-events-compat 兼容适配层（shim）
GrailsApplication,GrailsPluginManager,MongoEntityFormTagLib和ApplicationTagLib中已弃用的方法
到 2026 年，这些 API 早已不再是主流选择，但每一项都伴随着对应的测试基础设施、文档以及不可忽视的兼容性成本。将它们彻底移除，不仅缩减了 Grails 为应对未来 Spring、Groovy 和 Hibernate 变更所需维护的公共接口边界，也让剩余的 API 更易于学习、编写文档和提供支持。
Grails 8 面向生产环境的重心
Grails 8 的设计围绕生产环境的实际运行需求：
开箱即用的可观测性默认配置：Spring Boot 4 的存活探针（Liveness Probe）与就绪探针（Readiness Probe）默认通过 Health 端点暴露。这意味着 Kubernetes 部署无需为每个应用额外编写样板代码，即可获得正确的探针行为。
可重复且可证明的构建：每个发布的 JAR 文件均附带软件物料清单（SBOM），且构建过程实现端到端可复现，便于安全团队验证构件来源。
日志默认配置契合现代基础设施：Logback 现在默认使用 UTF-8 编码写入日志文件，与 Log4j2 及主流容器日志采集工具保持一致。
可预测的插件兼容性提示信号：Grails Gradle 插件在配置阶段一旦检测到不兼容设置（例如在 BOM 中使用未启用 enforcedPlatform 的 grails-micronaut），便会立即报错，而非让构建过程在运行时以难以察觉的方式失败。
Grails 8 新特性一览
Grails 8 引入了一系列影响应用程序构建、配置和运行方式的变更。其中部分变更较为渐进，而另一些则反映了平台层面的根本性变革。
核心框架与依赖更新
Grails 8.0.0-M1 的主要变更包括：
Spring Boot 4.0.5 与 Spring Framework 7.0.6（PR #15541）。
Spring Boot 自动配置模块化：原先单体式的 spring-boot-autoconfigure JAR 已被移除；自动配置类现已拆分至领域专用模块中，如 spring-boot-webmvc、spring-boot-servlet 和 spring-boot-mongodb。Grails 8 通过拆分的 BOM（依赖物料清单）无缝适配了这一新布局（PR #15608）。
Jackson 3（tools.jackson.*）成为默认 JSON 映射器：Jackson 注解仍保留在 com.fasterxml.jackson.annotation.* 命名空间下，并明确允许与 Jackson 3 配合使用，因此现有的 DTO 和领域类无需修改。Spring Boot 的部分辅助类已重命名（例如 Jackson2ObjectMapperBuilderCustomizer 改为 JsonMapperBuilderCustomizer，@JsonC
omponent 改为 @JacksonComponent 等）。Hibernate 7 升级正在推进中：通过 8.0.x-hibernate7 分支的 PR #15568 进行。Grails 8.0.0-M1 目前仍默认附带 Hibernate 5.6.15.Final。
Hibernate 兼容包内嵌处理：Spring Framework 7 已彻底移除 org.springframewor
k.orm.hibernate5 包。Grails 8 将该包直接内嵌（vendor）至全新的 grails-data-hibernate5
-spring-orm 模块（位于org.grails.orm.hibern
ate.support.hibernate5 路径下），确保 Grails 托管的 Hibernate 集成继续无缝工作。若应用在代码中直接导入了这些 Spring 类，则需手动更新包名。Spring Security 更新（PR #15609）：grails-spring-security 插件已同步刷新，并将遵循独立的发布节奏持续跟进。
Gradle 9.4.1 工具链：Grails Forge 项目生成器与 grails-micronaut 集成已全面升级至 Micronaut 4 / Micronaut Platform 5（PR #15365）。
CLI 交互依赖升级：Grails Shell 命令行界面现已采用 JLine 3.30.6 与 Jansi 2.4.2（PR #15367）。
测试框架更新：基于浏览器的功能测试现使用 Geb 8.0.1，同时集成 JUnit 6.0.3 与 Spock 2.3-groovy-4.0。
资源管线更新：位于 cloud.wondrify 坐标下的 Asset Pipeline 已升级至 5.1.0-M4（该坐标变更始于 Grails 7）。
Grails 8 的 Java 版本基线
Grails 8 要求使用 Java 21 来构建和运行应用程序，相较于 Grails 7 的 Java 17 要求有所提升。Java 21 是一个拥有广泛生态系统支持的长期支持（LTS）版本。Grails 团队选择 Java 21 而非更激进的基线版本（例如同样是 LTS 的 Java 25），主要基于以下两个实际原因：
1. 与现有工具生态系统的LTS 周期对齐：Java 21 在各大 OpenJDK 发行版（如 Temurin、Corretto、Liberica、Microsoft Build of OpenJDK、Oracle、Semeru）中均提供多年的供应商支持，这与大多数企业团队规划的技术支持周期相匹配。Java 25 虽然同样是 LTS 版本且更新，但工具生态系统（如构建代理、容器镜像、IDE 集成、第三方插件兼容性矩阵）通常需要 6 至 12 个月才能完全适配新的 LTS 版本。
2. 为插件提供可预期性：Grails 拥有规模庞大的第三方插件生态系统。将基线设定为 Java 21，可使这些插件针对稳定的字节码版本和标准库 API进行开发，而无需追逐后续版本中的预览特性或已敲定的 JEP（JDK 增强提案）。
但存在一个重要的例外：使用 grails-micronaut 集成的应用程序必须在 JDK 25 或更高版本上运行。这并非 Grails 的决策，而是 Micronaut 的要求：Micronaut Core 的 io.micronaut.core.
propagation.ScopedValues 引用了 java.lang.
ScopedValue.CallableOp，而该类型仅在 JDK 25 中才存在（当 JEP 506 正式确定 ScopedValue 规范时，内部类型从 Callable 重命名为 CallableOp）。若在 JDK 21 至 JDK 24 上运行 Micronaut，会在运行时因找不到该类而失败，并抛出 NoClassDefFoundError:java/lang/
ScopedValue$CallableOp 异常。Grails Forge 生成器会在项目生成阶段强制执行此要求，若 JDK 版本过低，Grails Gradle 插件也会给出明确的错误提示。不使用任何 Micronaut 集成的应用程序则不受此影响，可继续在 JDK 21 上运行。
配置与约定更新
部分 Spring Boot 4 的变更已延伸至 Grails 的配置体系中：
MongoDB 属性命名空间：在Spring Boot 自身自动配置中，spring.data.mongodb.* 现已变更为 spring.mongodb.*。Grails GORM for MongoDB 插件使用的是其专属的 mongodb.* 命名空间，不受此次变更影响。
Jackson 属性结构调整：原有的 spring.jackson.read.* 和 spring.jackson.writ
e.*配置项已迁移至 spring.jackson.json.read.* 与 spring.jackson.json.write.* 路径下。对于大多数此类变更，spring-boot-properties-migrator 依赖项会在应用启动时发出警告。枚举序列化默认行为：正如 Grails 7.0.2 弃用公告中所宣布的，SimpleEnumMarshaller 现已正式成为 JSON 与 XML 枚举序列化的默认选项。枚举将被序列化为纯字符串值（例如 “SUBMIT”），而不再是带有类型元数据的冗长旧格式。此前通过配置 grails.converters.json.
enum.format: simple 显式启用的应用，现已可直接移除该配置。Spring Boot Starter重命名：spring-boot-starter-web 现已更名为 spring-boot-starter-webmvc；spring-boot-starter-aop 更名为 spring-boot-starter-aspectj；OAuth2 相关 Starter 也已统一添加 security- 前缀（例如 spring-boot-starter-security-oauth2-client 等）。为降低迁移阻力，Spring Boot 4 提供了一个过渡性的 spring-boot-starter-classic，它会引入完整的模块集合，但新代码应直接面向这些模块化的 Starter 进行开发。
WAR 包部署：面向外部容器（External-container）的 WAR 包，现已改用 spring-boot-starter-tomcat-runtime，取代了原先providedRuntime ‘org.springframework.boot:spring-boot-starter-tomcat’ 的惯用写法。内嵌 Tomcat（即 ./gradlew bootRun 命令及可执行 WAR 包的默认配置）则继续不变地使用 spring-boot-starter-tomcat。
构建、工具链与开发者体验
Gradle 版本覆盖管理：PR #15467 采用 Gradle 平台机制结合轻量级的 BOM 属性覆盖方案，取代了原有的 Spring 依赖管理插件。应用现在无需引入 Spring DM 插件，即可通过标准 Gradle 语法直接覆盖 BOM 托管的依赖版本。
基于方法的 TagLib 语法：PR #15465 为 Grails 标签库引入了基于方法的语法，在完全兼容传统闭包写法的同时，还提供了配套的性能基准测试与更新文档。
Shell CLI中的Apache Maven 解析器：grails-shell-cli 现已内嵌 Apache Maven 3.9.9 与 Maven Resolver 1.9.22，用于在传统交互式 Shell 中解析插件与依赖元数据。终端用户的 Grails 项目仍继续使用 Gradle 进行构建——此项变更仅影响 Shell CLI 自身的内部解析机制。
Grails Forge ：位于 start.grails.org 的应用生成器是创建新 Grails 8 的推荐方式；它能够自动应用正确的 BOM （物料清单）、enforcedPlatform 语义以及 JDK 版本强制规则。
发布前就绪性验证：新增的 verify-branch.sh 脚本（PR #15621）为提交者提供了一键式预检能力，可在打发布标签前快速确认构建是否具备可复现性、签名完整性与可发布性。
可复现、字节级一致的构件：PR #15625 实现了每个模块的 SBOM 与 Groovydoc 输出的字节级可复现，确保重复执行发布流程时生成的构件内容完全一致。
Grails 8 的性能与运行时行为
对于大多数应用而言，Grails 8 在运行时行为上应表现为平稳、渐进式的演进，因为 Spring Boot 4 本身并非以性能优化为核心目标的发布版本。在进行容量规划时，有几个具体细节值得注意：
启动时间：对于标准的 Grails MVC 应用，启动时间与 Grails 7 基本持平。Spring Boot 4带来了渐进式的启动优化，但并未实现数量级上的飞跃。
内存与资源占用：内存占用与资源开销与 Spring Boot 4 的默认配置保持一致。内嵌 Tomcat 仍是默认选项；而 Undertow 在 Grails 8 中暂时不受支持，原因是其尚未发布兼容 Servlet 6.1 的版本（因此 Grails Forge 项目生成器已不再将 Undertow 列为可选配置）。
Grails 8 中的弃用项与破坏性变更
与任何主要版本发布一样，Grails 8 移除了在先前版本中已被标记为弃用的功能。这些移除是经过深思熟虑的，旨在确保框架具备长期可维护性。官方升级参考文档为Grails 8 升级指南，其中详细罗列了每一项变更。
已移除的长期弃用功能
大部分删除操作已通过 PR #15565 合并。其中影响最为关键的几项移除包括：
Grails.web.JSONBuilder：已被 groovy.json.
StreamingJsonBuilder 取代。使用旧版构建器手动构建 JSON 的代码，必须迁移至流式构建器。
旧版枚举序列化器：JSON 与 XML 中冗长的 EnumMarshaller 已被移除；SimpleEnumMarshaller 现已作为默认实现注册。通过 render(MyEnum.VALUE as JSON) 直接渲染单个枚举值的操作，现在会抛出 ConverterException 异常（详见 PR #15212）。
@Mixin 注解与 AST 转换机制：包括MixinTargetAware 与 MixinTransformation均被移除。官方建议改用 Groovy特征（Traits） 或扩展模块（Extension Modules） 作为替代方案。
GORM 旧版命名查询：NamedCriteriaProxy、NamedQueriesBuilder 以及 GORM 的 @AutoTimestamp 注解已被移除。建议改用 GORM 的 where 查询、查找器（finders），或兼容 @CompileStatic 编译的查询 DSL。
插件过滤层级结构：
CompatibilityPluginFilter,PluginFilter,BasePluginFilter,IncludingPluginFilter,ExcludingPluginFilter,IdentityPluginFilter,PluginFilterRetriever 以及 BinaryGrailsPluginDescriptor 已全部移除。插件发现机制现已统一合并至现代化的插件管理器中。
AetherGrapeEngine / AetherGrapeEngine
Factory：grails-shell-cli 中内嵌的 Grape 解析器已被移除。Shell 环境中的 Maven 依赖解析现直接通过 Apache Maven Resolver 进行。grails-events-compat：Reactor 2 兼容层已被移除。仍在使用 reactor.bus.* 兼容类的应用，必须迁移至现代化的 grails-events API。
已弃用的标签库方法：FormTagLib 与 ApplicationTagLib 移除了约十几个长期标记为弃用的方法。完整移除清单请参阅官方升级指南。
Grails 8 中需要注意的行为变更
即使部分 API 依然保留，多个运行时默认行为也已发生调整：
@SpringBootTest 不再自动配置 MockMvc、WebClient 或 TestRestTemplate。原先依赖隐式注入的测试代码，现在必须显式添加 @AutoConfigureMockMvc、@AutoConfigureWebClient 或 @AutoConfigureTestRestTemplate 。
@MockBean 和 @SpyBean 已被移除，取而代之的是位于 org.springframework.test.context.bean.override.mockito 的 @MockitoBean 与 @MockitoSpyBean。新注解仅支持在测试类字段上声明，无法再用于 @Configuration 类中。
TestRestTemplate已迁移至 org.springframework.boot.resttestclient包下。
HttpStatus.MOVED_TEMPORARILY 已被移除。请改用 HttpStatus.FOUND——两者均表示 HTTP 302 状态码，运行时行为完全一致。
Spring Framework 7 已移除主题相关功能。ThemeResolver、ThemeSource、Theme、SimpleTheme 及 SessionThemeResolver 等类均已不复存在。原先依赖 Spring 主题动态切换样式表的应用，需改用配置属性或会话（Session）属性来实现等效功能。
Spring Retry 不再由 Spring Boot 4 托管。若应用直接使用 @Retryable、@EnableRetry 或 @Recover ，则需在 build.gradle 中显式声明该依赖。
Logback 日志文件默认编码已改为 UTF-8。原先基于过去使用平台默认字符集的日志采集管道（log scraping pipelines）必须切换为 UTF-8。
存活探针（Liveness）与就绪探针（Readiness
）现已默认在 Health 端点启用；如需关闭，可通过配置项 management.endpoint.health.pro
bes.enabled: false 进行禁用。
Grails 8 升级与迁移注意事项
对于一直跟进代码弃用（deprecation）情况并及时处理的团队而言，升级至 Grails 8 相对直接，但仍需审慎规划、稳步推进。此次升级本质上是从 Spring Boot 3 向 Spring Boot 4 的迁移，并在此基础上叠加了 Grails 专属的兼容性防护机制；大部分破坏性变更实际上源于上游平台的演进，而非 Grails 框架自身。
升级至 Grails 8 的实用迁移步骤
请遵循以下步骤，以简化从 Grails 7 到 Grails 8 的迁移过程：
1.升级至最新的 Grails 7.x 版本
Grails 7 已完成 javax.* 到 jakarta.* 的迁移，并将 Maven 坐标统一归集至 org.apache.grails。在升级至 Grails 8 之前，先在最新的 7.x 版本上完成这些基础迁移，可确保每个问题都独立暴露出来并逐一解决，避免在跨版本升级时集中爆发。
2.在升级至 Grails 8 前，彻底清理 Grails 7 中的所有弃用警告
所有在 Grails 7 中被标记为弃用的任何内容，在 Grails 8 中均已被正式移除。此处最有效的工具是 Spring Boot 的 spring-boot-properties-migrator 依赖：将其以 runtimeOnly 作用域引入项目，启动应用，逐一修复它输出的所有配置警告，确认无误后再将该依赖移除。
3.审查项目中直接引用的 Spring 导入
请在代码库中全局搜索以下路径或标识符：org.springframework.orm.hibernate5.*、com.
fasterxml.jackson.databind.*、org.springframe
work.boot.web.embedded.*、HttpStatus.MOVED
_TEMPORARILY，以及与 Spring Theme（主题）相关的类。《Grails 8 升级指南》已为上述每项内容提供了明确的替代方案与迁移示例，可按指引逐一替换。
4. 验证插件与自定义框架扩展
确认 build.gradle 中的每个 Grails 插件均已升级至兼容 Grails 8 的版本。对于使用 grails-micronaut 的项目，务必确保 BOM（物料清单） 已通过 enforcedPlatform 引入（若未正确配置，Grails Gradle 插件将在构建配置阶段直接导致构建失败）。
5.更新测试
在相关位置添加 @AutoConfigureMockMvc 或 @AutoConfigureTestRestTemplate；将 @Mock
Bean 替换为 @MockitoBean；同步更新 TestRest
Template 的导入路径。
6.规划 JDK 版本策略
JDK 21 为最低基线要求。若项目中任何位置使用了 Micronaut，则必须在 CI 环境与生产环境中就绪 JDK 25。采用混合部署模式的团队应在迁移前统一 JDK 版本标准。
7.使用类似生产环境的工作负载进行测试
Spring Boot 4 的默认配置变更（如 UTF-8 日志编码、探针默认启用、开发工具实时重载默认关闭）单看影响细微，但叠加后在预发环境中会变得明显。建议在升级后完整执行一次预生产测试。
8.密切关注启动时间与重载表现
Spring Boot 4 调整了多项开发工作流的默认配置（详见下一节）。对于中大型应用而言，代码重载速度将直接成为影响迁移期间开发效率的关键指标，需纳入实测评估。
Grails 8 开发中的代码重载选项
随着 Grails 应用规模的不断扩大，热重载速度往往是开发者反馈循环中显著变慢的一环。Grails 8 的发布正是做出明确选型决策、而非继续依赖默认配置的最佳时机。
Apache Grails 官方开发重载文档列出了 Grails 8 所支持的所有重载方案。对大多数团队而言，实际开发中最关键的三个选项是：
1.Spring Boot Developer Tools（开发者工具）
这是新生成 Grails 应用的默认配置，也是理想的起步方案。它采用双类加载器机制，能够在代码变更时自动重启应用上下文，并支持静态资源的实时重载。官方 Grails 文档对其扩展性有明确提示：“在应用规模较小时表现良好，但当应用变得非常庞大时，重启可能会变慢甚至失败。”对于中大型 Grails 应用，DevTools 重启通常需要数秒到数分钟，因为每次类路径变更都会触发全量应用上下文重建、清除内存状态、使 JIT 编译优化失效，并重新执行 @PostConstruct 初始化与应用引导逻辑。
2.IntelliJ IDEA 增强版热替换（调试模式）
在调试会话期间，该功能可直接重载已修改的类，而无需重启应用上下文。它虽能避免 DevTools 的全量重启，但受限于 JVM 热替换对“结构性变更”的硬性约束——除非您同时使用 JetBrains Runtime（JBR）并启用 -XX:+AllowEnhancedClassRedefinition 参数。在实际开发中，面对中大型应用，其重载时间感知上仍需数十秒，与 DevTools 相差无几。原因在于，绝大多数实质性代码变更（如新增方法、调整 Spring Bean 定义、修改 GORM 映射）恰恰属于 IDE 无法直接热替换的结构性变更。
3. JRebel
这是一款商业级 JVM 代理工具，通过字节码插桩（bytecode instrumentation）实现真正的热替换。它能够在不重启 JVM、不丢失应用状态的前提下，实时重载类、配置与资源。其重载过程几乎是瞬时的——即使在大型应用中，通常也远低于一秒，因为整个过程中没有任何组件被销毁或重建。JRebel 是 Grails 官方明确推荐用于高级重载需求的方案，提供了一流的 Grails / Spring Boot 集成支持，并配有专属的 IntelliJ IDEA 插件。
Grails 文档中也列出了 Hotswap Agent 与 原生 JVM 调试模式热替换。目前 Hotswap Agent 在 Grails 中仍被归类为实验性方案，且官方文档已明确记录其局限性；而原生 JVM 调试模式热替换仅支持非结构性变更。对于企业级 Grails 8 应用而言，两者均不适合作为核心重载方案，但在特定狭窄场景下仍具可用性。
此外，Spring Boot 4 自身调整了一项影响上述所有方案的默认配置：spring.devtools.livereload.
enabled 现已默认设为 false。Grails Forge 项目生成器会通过 application-development.yml 主动将其重新启用；但若您现有的 Grails 7 应用依赖于 devtools 的实时重载功能，升级至 Grails 8 后需手动添加此配置。
为什么为中大型 Grails 8 应用选择 JRebel？
给 Grails 8 团队的实际建议非常明确：对于小型应用，DevTools 完全够用。但随着应用规模的增长（事实上，任何值得迁移至 Grails 8 的项目通常都已具备相当体量），每次代码变更的重载耗时都会从几秒攀升至几十秒，在超大型企业级应用中甚至可能长达数分钟。
若将这一单次耗时乘以开发者每天产生的代码变更次数，答案便一目了然：几十秒的重载等待与 JRebel 不到一秒的即时重载之间的差距，直接决定了开发者是度过高效专注的一天，还是陷入频繁上下文切换的低效循环。
JRebel 的价值在 Grails 8 迁移影响最显著的场景中体现得尤为突出：
承载大量内存状态的应用：如缓存、定时任务、Spring Security 会话、GORM 连接池、消息队列及 WebSocket 连接等。DevTools 每次重载都会清空这些状态，而 JRebel 则能完整保留。
模块化与多项目 Grails 应用：在共享模块中仅修改一行代码，往往会触发所有下游依赖项目的级联重建。
使用 grails-micronaut 集成的应用：此类应用类路径更长、JDK 版本要求更高（JDK 25+），启动引导过程也更为繁重。
迁移工作本身：在迁移期间，您需要快速迭代处理 Spring Boot 4 的弃用警告、插件兼容性修复，以及 GSP/Groovy/Java 代码的连续变更。在整个迁移周期中，每次重载节省的每一秒，都会在整个迁移周期中不断累积放大。
对于正在对真实生产应用进行现代化升级的 Grails 8 团队而言，免费方案与 JRebel 在重载速度上的差距已足够显著——它不仅会实质性拉长整个迁移周期，更会直接影响团队在最终交付上线时的信心。
关于 Grails 8 的最终思考
Grails 8 的核心目标在于确保 Grails 继续作为一流框架，在现代化环境中高效构建与运行 JVM 应用。本次发布的各项变革，凝聚了团队多年来在生产环境中运行 Grails 的实战经验，标志着项目在 Apache 软件基金会治理下完成的首个完整开发周期，并清晰锚定生态系统的未来技术栈：Java 21、Spring Boot 4、Spring Framework 7、Hibernate 7 与 Jakarta EE 10。
对于已使用 Grails 7.x 的团队而言，只要日常已及时清理废弃警告，此次升级将是平稳渐进的，而非破坏性的重构。对于仍停留在 Grails 6.x 的团队，官方推荐的升级路径是：先迁移至最新的 Grails 7 版本，再逐步升级至 Grails 8。此项迁移工作建议在 Spring Boot 3.5.x 于 2026 年 6 月 30 日正式终止支持（EOL）之前完成。
只要团队制定周密的升级规划，Grails 8 必将成为下一代 Grails 应用稳定且功能强大的基础平台。更重要的是，它也是首个明确为开源社区长期治理与持续演进而设计的 Grails 版本。
Perforce中国合作伙伴—龙智
随着 Grails 8 的发布，现代 JVM 生态的性能与稳定性迈上了新台阶。但不可否认的是，更庞大的依赖、更高的 JDK 基线以及模块化的自动配置，也让中大型应用的启动与加载成本变得愈发沉重。
作为 JRebel 官方授权合作伙伴，龙智长期致力于为国内企业级 Java 团队提供研发效能工具及本土化技术支持。
想让您的开发者告别“改一行代码，倒一杯咖啡”的低效循环，在 Grails 8 时代快人一步吗？ 立即联系 JRebel 官方授权合作伙伴——龙智，申请 JRebel 免费试用，体验不到 1 秒的丝滑热重载！
官网：www.shdsd.com
电话：400-666-7732
邮箱：marketing@shdsd.com
最新文章
相关产品
