正如您可能從我的 Java EE 7 部落格文章 中瞭解到的，我們正在規劃 Spring Framework 5.0 系列，預計於 2016 年釋出。屆時我們將跟蹤 JDK 9 的釋出候選版本，因為我們的一個關鍵主題是全面支援 JDK 9。

Spring 5 的功能規劃仍在進行中。我們將在今年的 SpringOne 大會上提出更深入的計劃，敬請期待！儘管如此，我想借此機會就我們擬議的系統要求向您徵求反饋。

我們將最低要求提高到 JDK 8+。 這是先決條件，因為它使我們能夠在整個框架中擁有更清晰的程式碼庫，在我們核心介面中引入預設方法實現，並在我們的核心抽象中依賴 JDK 8 API 型別（例如 CompletableFuture、java.util.function 介面）。

我們也打算軟性升級 EE 基線。 現在，這有點棘手，因為我們實際上存在個別要求 - 我們需要考慮生產環境的企業採用水平。

• 我們將把要求提高到 Servlet 3.0+（我們目前的 Servlet 2.5 執行時相容性），但不會更高，因為我們希望 Spring 5 應用程式仍然可以在基於 EE 6 的伺服器上執行。有關為什麼這樣做不可避免的討論，請參閱我 之前的部落格文章，考慮到 Java EE 7 和大量仍基於 Servlet 3.0 API 的伺服器的市場狀況。
• 我們將保持 JMS 1.1+ 的相容性，因為除了 EE 7 問題之外，我們預計企業界的訊息代理不一定會升級到 JMS 2.0。Spring 的 JMS 支援無論如何都會自動適應 JMS 2.0，因此在功能上不應該有任何缺失。只是我們不得不繼續支援 2002 年時代的 JMS 1.1 API 真是令人遺憾……
• 我們希望將 JPA 升級到 2.1+ 和 Bean Validation 升級到 1.1+，但我們的手似乎被束縛住了：TomEE 1.7 和 JBoss EAP 6.4 內部有硬編碼的 JPA 2.0 和 Bean Validation 1.0 API，而 WebLogic 12.1.3 具有 JPA 2.1 但沒有 Bean Validation 1.1 API（儘管它們是相關的）。
• 這意味著我們將不得不繼續檢測 JPA 2.1 / BV 1.1，並自動適應它們 - 或者我們將需要本地捆綁 JPA 2.1 / BV 1.1 API jar 和相應的提供者。一個可能的結果是，我們將簡化我們的設定，朝著 JPA 2.1 的方向發展，只是透過回退檢查在執行時容忍 JPA 2.0，這類似於我們目前處理 Servlet 3.0 與 2.5 的方式。

從您的角度來看，上述假設是否可行？您是否有過透過本地打包應用程式中的相應 API 和提供者來單獨升級 EE 6 伺服器到 JPA 2.1 / Bean Validation 1.1 的經驗？歡迎任何反饋！

請注意：如果您仍在使用 JDK 6 或 7，無需擔心：我們也在規劃明年初發布 Spring Framework 4.3，它將在 Spring 4 的通用系統要求範圍內。然而，這將是該系列的最後一個功能版本，之後 Spring Framework 4.x 將進入純維護階段。