SpringOne开发者大会第二天的活动充满了惊喜，其中就包括Spring框架的领头人Juergen Hoeller和微软杰出工程师Erich Gamma博士（“四人帮”之一）的演讲。

2002年，Hoeller创建了Spring，据说他是在圣诞节期间阅读了Rod Johnson的一本书而受到了启发。

Hoeller的演讲充满了激情，提及了技术生态圈和整个社区的通力合作让Spring框架光芒四射，让各方利益相关者获益不浅。

以下是Hoeller的演讲摘选。

关于Spring在肩负行业责任方面所面临的挑战：

\

这么多年来，我很荣幸能够领导Spring框架的迭代开发。现在我们身处2017年，并向2018年迈进。我们再次面临同样的境遇，我们仍然面临很多挑战。Spring框架从来都不只是个孤岛，它向生态系统敞开怀抱，拥抱变化，拥抱JVM生态系统的基础设施。

\

关于如何赶上Java每六个月发布一次的节奏：

\

在这一时刻，我们正经历着Java生态系统最有趣的变化。我们有了最新的JDK 9，虽然它早在9月份就已发布。我们以后每半年就会拥有一个新的JDK。我们真的需要去拥抱这种变化。我们过去习惯了三年才获得一个新版本JDK，甚至是三年半，而现在时间缩短到了半年。不过新特性的发布频率并没有变，我们都是凡人，所以说这种节奏更快了。JDK 10将在2018年3月发布，而JDK 11将在2018年9月发布。它们可能只是小的特性发布版本，但却使用了大版本进行发行，每一次发布都提升了字节码版本。它们更像是9.2版本，不过它们确实带来了新的语言特性。以JDK 10为例，它将会带来新的本地变量声明方式，往JDK核心库中增加新特性就有了不一样的模式，它总是能够在合适的时间推出新特性。每半年就会有一个新JDK版本发布，所以我们等待新特性发布的时间不会超过半年。不过事情总是有它的两面性。每次新版本发布都会带来新的字节码版本，相关的工具需要为此做好准备。这或许会是一个挑战，会给Java生态系统带来混乱。很多工具都是基于字节码版本实现的，比如ASM、CGLib、ByteBuddy等，它们原本不需要因新的JDK发布而做出什么修改，但现在它们只能被限定在特定的JDK版本上，每次新JDK发布它们也要做出修改。我们不得不改变我们的思维，我们不得不改变我们的基础设施，改变我们的字节码处理方式，以便适应JDK的版本变化。现在JDK 10正在开发当中，我们将拥抱它，我们还会有JDK 11，我们安装好它，并用它运行我们的基础设施、已有的框架、已有的软件包，一切安好。我们只需要在思维方面做些改变。但要注意，并不是所有的JDK都有长期支持版本，我更关心的是长期支持版本。在生产环境，我们只会使用具有长期支持的JDK和JVM，而根据当前计划，我们每三年才能获得一个长期支持版本。但也许这也会发生变化，变化无处不在，但从目前来看，JDK 9并不是一个长期支持版本，JDK 10也不是。JDK 11有可能是，它将在明年的9月份发布。所以说，JDK 8是目前的长期支持版本，下一个会是JDK 11。这对于我们来说会是一个挑战，我们的Spring 5是基于Java 8版本开发的，这在Java生态系统里已经很常见了，很多软件包都是基于Java 8的。它们可以用在后续的JDK版本上，对于软件包、框架和生产环境来说，Java 8是一个参考点，而使用新版本JDK会是锦上添花。

\\

从Spring框架来看，我们已经准备好采用新的运行时环境。所以，Spring 5应用程序在JDK 9上运行是没有问题的，它甚至都能在JDK 10上运行，当然也能够在JDK 11上运行。JDK 8是最好的，JDK 9也不错，等JDK 10和JDK 11正式发布后也可以使用它们。

\

关于技术合作：

\

除了OpenJDK以及其他创造性的改进，还有其他很多有意思的东西，我们也参与其中。我们与JetBrains的Kotlin小组保持着良好的关系，我们很高兴能够与他们合作。我们的合作是双赢的，Spring 5的很多东西是受到了Kotlin的启发而开发的。不仅仅是基于Kotlin的应用，我们把很多来自Kotlin的设计点子融入到Spring 5当中，Kotlin的很多语法可以被很好地映射到Java生态系统中。Kotlin中有很多重要的模式，尽管Spring 5已经包含了很多内容，但Kotlin的这些模式仍然给我们带来很多启发，我们将会把它们应用到Spring 5当中。如果大家选择Kotlin来实现Spring应用，Spring框架和API也已经为此做好了准备。我们在支持Kotlin方面已经走得很远。这是一种良性的关系，我们发现问题，他们来修复，我们可以达成我们想要的一切，这就是我们在技术合作方面最好的例子。

\\

另一个合作领域是关于反应式流——Reactor项目是基于响应式流的，是响应式流生态系统的一部分。我们与RxJava团队和Lightbend的响应式流团队也有着密切的合作关系。我们有共同的语言词汇表、技术术语、语义以及运行时契约。但事情太多了，我们努力达成最大程度的一致，让现有的RxJava能够适用于使用了Reactor的应用程序上。

\\

最近发布了EE4J，我们看到了Java EE的终结，而EE4J是JCP的新贵，在我们看来它就是Java EE。Servlet规范、JPA、Bean Validation都捐献给了Eclipse基金会，处于EE4J的庇护之下。这是我们参与规范工作的最好时机。我们已经在Servlet规范上投入了很多，我们已经成为JPA专家组成员很长一段时间了，我们也集成Bean Validation好几年了。我们最近开始拥抱JSON Binding API——谷歌Gson的替代品。我们正在参与好几个规范，只等Eclipse基金会这边开始流程。我们极有可能看到更多小版本的规范出现，可能是JPA 2.3、Servlet 4.1，不一定要再等4年，有可能是明年或2019年，只要所有的利益相关者同意发布。如果Tomcat和Jetty同意Servlet 4需要做一些API重构，那么它们就会在Servlet 4.1中发布，这会在某个合适的时间发生。

\\

我们参与了这么多的项目，很多实际的例子证实我们已经带来了很大的价值，而在2018年会有更大的价值得到体现。Kotlin 1.3协程模型，我们将会在适当的时机拥抱它，或许是在2018年或2019年。

\

关于Spring核心框架的路线图：

\

从Spring框架角度来看，我们已经准备好开始新任务。Spring 5已经包含了很多东西，新的函数式API设计、反应式架构、反应式Web技术栈、将Kotlin作为另一个首选的JVM语言。它们都很健壮，可以长期存在。我们的使命尚未结束，我们已经开启了新一代框架，我们正在迭代，从人们那里收集反馈——每一个利益相关者、Kotlin团队成员、Reactor团队成员。除了这些，在2018年，我们有两个主要迭代计划，都是在核心框架层面。我们计划在2018年5月或6月初推出Spring 5.1。我们的JIRA待办目录中有很多东西需要做，如果大家想知道明年Spring框架会发生什么变化，可以参看JIRA的5.x目录。那里有差不多200个待办事项，如果大家关心其中某些项目，可以给它们投票，或者给出评论，表达你们的想法，我们会依此决定明年的优先级。如果有些东西无法在5.1中交付，我们会另找机会，随着新JDK的发布，或许可以放在下一年年底的Spring 5.2中发布。将依赖项更新到最新版，采用最新的Kotlin，反应式流的新进展，反应式JDBC集成API，这些东西都有可能包含在后续的5.1、5.2甚至是2019年的5.3版本当中。

\\

我们野心勃勃，同时几个项目齐头并进，我们希望为大家带来更多东西，2018年将是激动人心的一年，我个人非常期待我们将给大家带来的惊喜。

\

查看英文原文：