Micronaut使用提前編譯支援Spring Boot
隨著Micronaut 1.0.1 的釋出，OCI的Micronaut團隊很高興地宣佈推出Micronaut for Spring 1.0 M1 。
Micronaut for Spring增加了使用歷史悠久的基於Spring註釋的程式設計模型來構建與Micronaut和Spring一起使用的Micronaut應用程式和庫的能力。
提供的示例應用程式 在源級別是Spring Boot應用程式。使用提前（AOT）編譯，Micronaut能夠計算和解釋Spring註釋程式設計模型，並生成有效的Micronaut應用程式，而不會增加任何執行時開銷。然後，可以在GraalVM上執行Micronaut應用程式。
Micronaut有一組註釋，在執行時用於實現框架。Spring有另一套可以簡單地對映到Micronaut的註釋上。您可以將這些註釋視為原始碼級域特定語言（DSL）。
在編譯時，解釋註釋元資料並將Spring註釋對映到等效的Micronaut註釋元資料，就像這樣，Micronaut可以執行Spring應用程式。
請注意，只支援Spring的一個子集，但它足以構建真正的應用程式和庫，無論它們是否包含在Spring Boot應用程式或Micronaut應用程式中。
支援Spring Boot的好處
儘管在應用程式依賴項中包含Spring對於Micronaut開發人員來說有一些缺點（特別是JAR大小從13MB增加到29MB），但使用Spring註釋程式設計模型也有一些有趣的好處，包括：
- 工具支援。如果將應用程式匯入到Spring感知IDE（例如IntelliJ IDEA或STS 4.0）中，則Spring的功能“正常工作”。這是有道理的，因為IDE在原始碼上執行，因此就IDE而言，應用程式是一個Spring應用程式，即使在執行時該應用程式實際上是一個Micronaut應用程式。Spring生態系統中的任何原始碼級工具都是如此。
- Spring和Grails的相容性。通過使用Spring註釋程式設計模型，可以構建與Spring Boot，Grails和Micronaut一起使用的自動配置，端點，控制器和庫。
- 更容易遷移到Micronaut。雖然不是Spring的每個功能都得到支援，但絕大多數重要方面都是。這樣可以更輕鬆地培訓新開發人員，遷移現有程式碼並使用Micronaut。
請注意，如果您的原始碼僅引用Spring註釋而不是Spring介面，則Spring實際上可以是“僅編譯”依賴項，這會將JAR大小縮減回13MB並帶來上述所有好處。
對於Spring開發者好處
對於Spring開發人員來說，好處也很多。
由於效能或記憶體消耗限制，Micronaut能夠採用以前從未能夠實現的Spring程式設計模型：
- 物聯網（IoT）。 Micronaut在物聯網場景中執行良好，包括在Raspberry Pi上。這是因為Micronaut應用程式的記憶體配置檔案與Spring或Jakarta EE應用程式無關，可以節省大量成本。
- GraalVM。 Micronaut是第一個以真實的方式將真正的Spring程式設計模型引入GraalVM的框架。您可以在GraalVM上的原始碼級別執行本質上是Spring Boot的應用程式，並實現閃電般快速的功能和低記憶體佔用的微服務。
- Android系統。 我記得在SpringSource的早期階段，將Spring程式設計模型引入Android的野心。它從未發生過; 只有像RestTemplate這樣的小型Spring元件才能進入Android。Micronaut核心容器已在Android上執行， 並有可能將整個Spring程式設計模型引入Android。我們對Android上的Micronaut抱有很大的抱負。
- AOT編譯。Micronaut可以被認為是AOT的框架，具有完整的API，可以跨語言實現執行許多AOT任務。例如，引用的示例 應用程式能夠在編譯時通過Micronaut計算Swagger API元資料，即使實際上沒有引用Micronaut API。
- 無伺服器。藉助Micronaut更快的冷啟動和更低的記憶體成本，構建使用Spring程式設計模型的高效應用程式變得更加容易。
- 庫相容性。 JHipster和Spring Boot Admin等專案現在可以將Micronaut for Spring作為編譯時註釋處理器，並與Spring Boot和Micronaut一起使用。這對圖書館生態系統來說是個大新聞。
- spring的Micronaut功能。 由於註釋對映適用於任何類，因此您可以獲得基於Spring註釋的編譯時宣告性HTTP客戶端， 並且可以使用任何其他Micronaut功能。
如上所述，使用Micronaut for Spring，現在技術上也可以編寫Spring Boot，Micronaut和Grails的Spring Boot自動配置。Pivotal的Spring團隊甚至可以使用這個庫，並使用Spring Boot或Micronaut 進行大量的spring-boot-autoconfigure。
這樣做的方式是Spring Boot在執行時計算自動配置，而如果編譯時元資料在那裡，Micronaut會自動載入它而不需要額外的執行時計算。
由於Micronaut也可以用作Spring Boot的父應用程式上下文，因此Spring Boot的核心甚至可以更新為使用Micronaut進行內部連線，併為Spring Boot帶來GraalVM相容性。如果Pivotal開發人員感興趣，我們很樂意聊天 。
GRAILS開發人員有什麼用？
我們為Spring開發Micronaut的主要原因實際上是Grails 4.0。
我已經開始研究Grails 4.0，作為規劃的一部分，我們希望Grails開發人員能夠從我們在過去一年中對Micronaut的投資中獲益。
在Grails 4.0中，Micronaut將接替Grails應用程式的父上下文，Grails的大部分內部連線將基於Micronaut而不是Spring，這樣我們就可以減少記憶體消耗並縮短啟動時間。結合Spring團隊在Spring Boot 2.1中所做的改進，將在記憶體消耗和啟動時間方面對Grails 4.x應用程式進行重大改進。
由於Micronaut將成為Grails 4.0應用程式的父上下文，這也意味著我們為Micronaut開發的每個功能都可以在Grails 4.0應用程式中使用，從編譯時客戶端（如HTTP客戶端 和Kafka客戶端 ）到服務等功能發現和客戶端負載平衡。
與MICROPROFILE關係
我很高興與參與MicroProfile的 一些人聊天，雖然專案的目標很有趣，但任何基於通過反射註釋的執行時分析的模型都會遭遇記憶體消耗問題，因此我對目前的實施效能表示懷疑。。
說到這一點，並且已經閱讀了規範，Micronaut能夠使用AOT在編譯時支援任何註釋集，這意味著Micronaut可以使用與Micronaut for Spring相同的方法在技術上支援MicroProfile。
換句話說，沒有理由通過對映註釋和提供一些介面橋來實現基於JAX-RS / CDI的MicroProfile實現。
總結
當我今年早些時候在Greach首次推出Micronaut時，我提到Micronaut不僅僅是另一個HTTP伺服器實現（用Java編寫的新HTTP伺服器似乎每週都會出現在Github上！）。Micronaut有可能徹底改變典型Spring和/或Jakarta EE應用程式的執行時特性，同時保留開發人員熟悉和喜愛的大部分功能集，從而徹底改變JVM應用程式的構建方式。
通過使JVM使用者可以訪問AOT並跨語言（目前是Java，Kotlin和Groovy）實現AOT的相容性，Micronaut能夠將原始碼與執行時環境分離，就像之前沒有其他框架一樣。