作為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 座標已統一為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 Framework 7 移除了自身的 springframework.orm.hibernate5 包，並採用了 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/MixinTransformation機制
- 已棄用的 ConstraintsEvaluator
- CompatibilityPluginFilter 及整個 PluginFilter 層級結構
- BinaryGrailsPluginDescriptor
- CorePluginFinder（核心插件查找器）
- AetherGrapeEngine 與 AetherGrapeEngineFactory
- 原始的 gson-views JSON 生成器類
- GORM AutoTimestamp 注解以及 NamedCriteriaProxy / NamedQueriesBuilder 命名查詢基礎設施（僅其測試類就超過 1,000 行代碼）
- grails-events-compat 相容適配層（shim）
- GrailsApplication、GrailsPluginManager、MongoEntity、FormTagLib和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（jackson.*）成為默認 JSON 映射器：Jackson 注解仍保留在 com.fasterxml.jackson.annotation.* 命名空間下，並明確允許與 Jackson 3 配合使用，因此現有的 DTO 和領域類無需修改。Spring Boot 的部分輔助類已重命名（例如 Jackson2ObjectMapperBuilderCustomizer 改為 JsonMapperBuilderCustomizer，@JsonComponent 改為 @JacksonComponent 等）。
- Hibernate 7 升級正在推進中：通過 0.x-hibernate7 分支的 PR #15568 進行。Grails 8.0.0-M1 目前仍默認附帶 Hibernate 5.6.15.Final。
- Hibernate 相容包內嵌處理：Spring Framework 7 已徹底移除 springframework.orm.hibernate5 包。Grails 8 將該包直接內嵌（vendor）至全新的 grails-data-hibernate5-spring-orm 模組（位於org.grails.orm.hibernate.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），主要基於以下兩個實際原因：
- 與現有工具生態系統的LTS 週期對齊：Java 21 在各大 OpenJDK 發行版（如 Temurin、Corretto、Liberica、Microsoft Build of OpenJDK、Oracle、Semeru）中均提供多年的供應商支持，這與大多數企業團隊規劃的技術支持週期相匹配。Java 25 雖然同樣是 LTS 版本且更新，但工具生態系統（如構建代理、容器鏡像、IDE 集成、第三方插件相容性矩陣）通常需要 6 至 12 個月才能完全適配新的 LTS 版本。
- 為插件提供可預期性：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 自身自動配置中，data.mongodb.* 現已變更為 spring.mongodb.*。Grails GORM for MongoDB 插件使用的是其專屬的 mongodb.* 命名空間，不受此次變更影響。
- Jackson 屬性結構調整：原有的 jackson.read.* 和 spring.jackson.write.* 配置項已遷移至 spring.jackson.json.read.* 與 spring.jackson.json.write.* 路徑下。對於大多數此類變更，spring-boot-properties-migrator 依賴項會在應用啟動時發出警告。
- 枚舉序列化默認行為：正如 Grails 7.0.2 棄用公告中所宣佈的，SimpleEnumMarshaller 現已正式成為 JSON 與 XML 枚舉序列化的默認選項。枚舉將被序列化為純字串值（例如 “SUBMIT”），而不再是帶有類型元數據的冗長舊格式。此前通過配置 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 ：位於 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 合併。其中影響最為關鍵的幾項移除包括：
- 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 / AetherGrapeEngineFactory：grails-shell-cli 中內嵌的 Grape 解析器已被移除。Shell 環境中的 Maven 依賴解析現直接通過 Apache Maven Resolver 進行。
- grails-events-compat：Reactor 2 相容層已被移除。仍在使用 bus.* 相容類的應用，必須遷移至現代化的 grails-events API。
已棄用的標籤庫方法：FormTagLib 與 ApplicationTagLib 移除了約十幾個長期標記為棄用的方法。完整移除清單請參閱官方升級指南。
Grails 8 中需要注意的行為變更
即使部分 API 依然保留，多個運行時默認行為也已發生調整：
- @SpringBootTest 不再自動配置 MockMvc、WebClient 或 TestRestTemplate。原先依賴隱式注入的測試代碼，現在必須顯式添加 @AutoConfigureMockMvc、@AutoConfigureWebClient 或 @AutoConfigureTestRestTemplate 。
- @MockBean 和 @SpyBean 已被移除，取而代之的是位於 springframework.test.context.bean.override.mockito 的 @MockitoBean 與 @MockitoSpyBean。新注解僅支持在測試類字段上聲明，無法再用於 @Configuration 類中。
- TestRestTemplate已遷移至 springframework.boot.resttestclient包下。
- MOVED_TEMPORARILY 已被移除。請改用 HttpStatus.FOUND——兩者均表示HTTP 302 狀態碼，運行時行為完全一致。
- Spring Framework 7 已移除主題相關功能。ThemeResolver、ThemeSource、Theme、SimpleTheme 及 SessionThemeResolver 等類均已不復存在。原先依賴 Spring 主題動態切換樣式表的應用，需改用配置屬性或會話（Session）屬性來實現等效功能。
- Spring Retry 不再由 Spring Boot 4 託管。若應用直接使用 @Retryable、@EnableRetry 或 @Recover ，則需在 gradle 中顯式聲明該依賴。
- Logback 日誌檔默認編碼已改為 UTF-8。原先基於過去使用平臺默認字元集的日誌採集管道（log scraping pipelines）必須切換為UTF-8。
存活探針（Liveness）與就緒探針（Readiness）現已默認在 Health 端點啟用；如需關閉，可通過配置項 management.endpoint.health.probes.enabled: false 進行禁用。
Grails 8 升級與遷移注意事項
Atlassian被Forrester評為企業服務管理的“領導者”
對於一直跟進代碼棄用（deprecation）情況並及時處理的團隊而言，升級至 Grails 8 相對直接，但仍需審慎規劃、穩步推進。此次升級本質上是從 Spring Boot 3 向 Spring Boot 4 的遷移，並在此基礎上疊加了 Grails 專屬的相容性防護機制；大部分破壞性變更實際上源於上游平臺的演進，而非 Grails 框架自身。
升級至 Grails 8 的實用遷移步驟
請遵循以下步驟，以簡化從 Grails 7 到 Grails 8 的遷移過程：
- 首先升級至最新的 Grails 7.x 版本。Grails 7 已完成 javax.* 到 jakarta.* 的遷移，並將 Maven 座標統一歸集至 org.apache.grails。在升級至 Grails 8 之前，先在最新的 7.x 版本上完成這些基礎遷移，可確保每個問題都獨立暴露出來並逐一解決，避免在跨版本升級時集中爆發。
- 在升級至 Grails 8 前，徹底清理 Grails 7 中的所有棄用警告。所有在 Grails 7 中被標記為棄用的任何內容，在 Grails 8 中均已被正式移除。此處最有效的工具是 Spring Boot 的 spring-boot-properties-migrator 依賴：將其以 runtimeOnly 作用域引入專案，啟動應用，逐一修復它輸出的所有配置警告，確認無誤後再將該依賴移除。
- 審查專案中直接引用的 Spring 導入。請在代碼庫中全局搜索以下路徑或識別字：org.springframework.orm.hibernate5.*、com.fasterxml.jackson.databind.*、org.springframework.boot.web.embedded.*、HttpStatus.MOVED_TEMPORARILY，以及與 Spring Theme（主題）相關的類。《Grails 8 升級指南》已為上述每項內容提供了明確的替代方案與遷移示例，可按指引逐一替換。
- 驗證插件與自定義框架擴展：確認 build.gradle 中的每個 Grails 插件均已升級至相容 Grails 8 的版本。對於使用 grails-micronaut 的專案，務必確保 BOM（物料清單）已通過 enforcedPlatform 引入（若未正確配置，Grails Gradle 插件將在構建配置階段直接導致構建失敗）。
- 更新測試：在相關位置添加 @AutoConfigureMockMvc 或 @AutoConfigureTestRestTemplate；將 @MockBean 替換為 @MockitoBean；同步更新 TestRestTemplate 的導入路徑。
- 規劃 JDK 版本策略：JDK 21 為最低基線要求。若專案中任何位置使用了 Micronaut，則必須在 CI 環境與生產環境中就緒 JDK 25。採用混合部署模式的團隊應在遷移前統一 JDK 版本標準。
- 使用類似生產環境的工作負載進行測試：Spring Boot 4 的默認配置變更（如 UTF-8 日誌編碼、探針默認啟用、開發工具即時重載默認關閉）單看影響細微，但疊加後在預發環境中會變得明顯。建議在升級後完整執行一次預生產測試。
8. 密切關注啟動時間與重載表現：Spring Boot 4 調整了多項開發工作流的默認配置（詳見下一節）。對於中大型應用而言，代碼重載速度將直接成為影響遷移期間開發效率的關鍵指標，需納入實測評估。
Grails 8 開發中的代碼重載選項
隨著 Grails 應用規模的不斷擴大，熱重載速度往往是開發者回饋迴圈中顯著變慢的一環。Grails 8 的發佈正是做出明確選型決策、而非繼續依賴默認配置的最佳時機。
Apache Grails 官方開發重載文檔列出了 Grails 8 所支持的所有重載方案。對大多數團隊而言，實際開發中最關鍵的三個選項是：
- Spring Boot Developer Tools（開發者工具）：這是新生成 Grails 應用的默認配置，也是理想的起步方案。它採用雙類加載器機制，能夠在代碼變更時自動重啟應用上下文，並支持靜態資源的即時重載。官方 Grails 文檔對其擴展性有明確提示：“在應用規模較小時表現良好，但當應用變得非常龐大時，重啟可能會變慢甚至失敗。”對於中大型 Grails 應用，DevTools 重啟通常需要數秒到數分鐘，因為每次類路徑變更都會觸發全量應用上下文重建、清除記憶體狀態、使 JIT 編譯優化失效，並重新執行 @PostConstruct 初始化與應用引導邏輯。
- IntelliJ IDEA 增強版熱替換（調試模式）：在調試會話期間，該功能可直接重載已修改的類，而無需重啟應用上下文。它雖能避免 DevTools 的全量重啟，但受限於 JVM 熱替換對“結構性變更”的硬性約束——除非您同時使用 JetBrains Runtime（JBR）並啟用 -XX:+AllowEnhancedClassRedefinition 參數。在實際開發中，面對中大型應用，其重載時間感知上仍需數十秒，與 DevTools 相差無幾。原因在於，絕大多數實質性代碼變更（如新增方法、調整 Spring Bean 定義、修改 GORM 映射）恰恰屬於 IDE 無法直接熱替換的結構性變更。
- 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 版本。
結語
隨著 Grails 8 的發佈，現代 JVM 生態的性能與穩定性邁上了新臺階。但不可否認的是，更龐大的依賴、更高的 JDK 基線以及模組化的自動配置，也讓中大型應用的啟動與加載成本變得愈發沉重。
作為 JRebel 官方授權合作夥伴，龍智長期致力於為國內企業級 Java 團隊提供研發效能工具及本土化技術支持。
開啟您的極致開發體驗：
想讓您的開發者告別“改一行代碼，倒一杯咖啡”的低效迴圈，在 Grails 8 時代快人一步嗎？ 立即聯繫 JRebel 官方授權合作夥伴——龍智，申請 JRebel 免費試用，體驗不到 1 秒的絲滑熱重載！
官網：https://hkdsdtech.com/hk
電話：+852-51679050
郵箱：customer@hkdsdtech.com
