請注意，還有一篇關於 Spring 5 系統要求的後續部落格文章。如果您主要對 Spring 5 的規劃過程感興趣，您可能想從那裡開始。

為了追求 Java EE 整合，我們正積極擁抱最新一代的規範，例如 JPA、Bean Validation，當然還有 Servlet 和 JMS API。 從 Spring 4 開始，我們並排支援 Java EE 6 和 7 級別的規範。 我們希望儘快將其提升到 EE 7+ 級別（JPA 2.1、Bean Validation 1.1，特別是 Servlet 3.1 和 JMS 2.0），但面臨一個根本問題：缺乏對 EE 7 平臺的採用。

Java EE 7 平臺已於 2013 年 5 月釋出，至今已有兩年。 令人驚訝的是，它幾乎沒有在生產中找到。 但實際上這並不令人意外：雖然 在此期間一些專案已經通過了 EE 7 認證，但主要供應商的缺乏顯而易見： 目前還沒有主要的 EE 7 伺服器提供生產支援，無論是 Web Profile 還是完整平臺。 截至 2015 年 6 月，常見的 EE 供應商仍在銷售基於 2009 年代 Java EE 6 API 的伺服器的許可證。 而且不僅僅是傳統的嫌疑人。

• Tomitribe 提供對 TomEE 1.7 的支援，這是一個基於 Tomcat 7 的 EE 6 Web Profile 堆疊，基於 2009 年代的 EE 6 API，但至少與 JSR-356 WebSockets 和 JDK 8 相容。 TomEE 7.0（最近從 TomEE 2.0 重新命名）將是基於 Tomcat 8 的 Java EE 7 Web Profile 產品，但尚未釋出（截至 2015 年 6 月）。
• Red Hat 最近的支援產品是 JBoss EAP 6.4，這是一個基於 JBoss 7 的 EE 6 堆疊，支援 JSR-356 WebSockets 和 JDK 8。 請注意，從 Red Hat 的角度來看，WildFly 是一個研發專案：它會頻繁釋出功能（值得稱讚），但不幸的是，沒有維護版本或任何形式的生產支援。
• Oracle 釋出了 WebLogic 12.1.3，這是一個 EE 6 伺服器，帶有一點 EE 7（JPA 2.1、JAX-RS 2.0、JSR-356 WebSockets）和 JDK 8 支援。 作為完整 EE 7 伺服器的 WebLogic 12.2.1（之前曾宣佈為 12.1.4）仍未釋出（截至 2015 年 6 月）。 從 Oracle 的角度來看，GlassFish 4 只是一個 RI，WebLogic 是生產升級路徑。
• IBM WebSphere 團隊在為 WebSphere Liberty Profile (WAS 8.5.5) 實現 EE 7 規範方面做得很好，但尚未完成這項工作。 至少，某些 EE 7 模組和 JDK 8 已經以 Liberty Profile 的一種功能包的形式在生產中得到支援，並且 WebSphere 完整的 Java EE 7 認證很可能仍然會在 2015 年完成。

最新訊息（6 月 9 日）：WAS 8.5.5 的 EE 7 修復包將於 6 月 26 日正式釋出。 贊一個，IBM！

雖然來自 EE 7 保護傘的一些規範已經看到了單獨的採用，例如透過 Hibernate 4.3 實現的 JPA 2.1 和透過 Tomcat 8 和 Jetty 9 實現的 Servlet 3.1 / JSR-356 WebSockets，但公平地說，Java EE 7 未能作為整體平臺進入市場。 畢竟，“平臺”的意義在於廣泛的主流可用性。 具有諷刺意味的是，後來釋出的 JDK 8（2014 年 3 月）在生產中得到了相當快的採用，即使在 EE 領域也是如此！ 因此，截至 2015 年年中，最先進的技術是執行在 JDK 8 上的供應商支援的 Java EE 6 伺服器...

我們的結論：鑑於 Spring 4 和 Java 8 的採用率，我們將把 Spring Framework 5 這一代的最低要求提高到 JDK 8+。 但是，由於缺乏對 Java EE 7 平臺的採用，我們將不得不保留與當前一代應用伺服器的相容性：允許即將推出的 Spring 5 應用程式部署到通常在生產中找到的基於 JDK 8 的 EE 6 伺服器 - 就像我們已經使用 Spring 4 所做的那樣，但至少具有為我們的框架程式碼庫及其所有核心介面採用 JDK 8+ 的額外好處。

附言（6 月 6 日）

順便說一句，我真的很欣賞 GlassFish 和 WildFly 作為開源工程的努力。 Spring 專門為兩者提供支援，並且 Undertow HTTP 伺服器（在 WildFly 保護傘下）非常適合與 Spring Boot 的嵌入式部署。 這並沒有改變專案所有者（分別是 Oracle 和 Red Hat）不提供支援的事實，而是選擇投資於 WebLogic 12 和 JBoss EAP 6 以用於生產目的。 來自 Payara（針對 GlassFish）等外部支援只能在一定程度上緩解這種情況，Java EE 市場的大部分都繫結到供應商的生產產品（全部基於 EE 6），而 2015 年的情況就是如此。

有關開源專案本身提供良好生產支援的示例，請參考 Tomcat。 Tomcat 專案在修復錯誤，尤其是安全漏洞方面有著令人欽佩的記錄，即使在伺服器的過去三代主要版本中也是如此。 所以我不是在爭論商業支援本身，我是在爭論像 Tomcat 那樣進行適當的維護版本（並且我敢說：像 Spring 那樣），無論是來自開源專案本身還是來自商業支援訂閱。 例如，WildFly 沒有這兩者中的任何一個； GlassFish 沒有來自 Oracle 的支援，但至少可以透過 Payara 獲得支援選項。