正如你可能从我的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 的方式。

从您的角度来看，上述假设是否可行？ 您是否有单独将 EE 6 服务器升级到 JPA 2.1 / Bean Validation 1.1 的经验，例如通过在应用程序中本地发布相应的 API 和提供程序？ 欢迎任何反馈！

请注意：如果您仍然使用 JDK 6 或 7，则无需担心：我们还计划在明年年初发布 Spring Framework 4.3，在通常的 Spring 4 系统要求范围内。 但是，这将是该系列的最后一个功能版本，Spring Framework 4.x 随后将进入纯维护阶段。