正如您可能从我的 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 将进入纯维护阶段。