BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Juergen Hoeller谈Spring 3.1与Spring 3.2
录制于:

| 受访者 Jüergen Hoeller 关注 1 他的粉丝 作者 Charles Humble 关注 936 他的粉丝 发布于 2011年6月10日 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。
29:03

个人简介 Juergen Hoeller是Spring框架的联合创始人,自2003年2月Rod的Interface21将Spring框架开源起,他就是最活跃的Spring开发者。Juergen是一名经验丰富的咨询师,擅长于Web应用、事务管理、O/R映射技术以及轻量级远程调用。

QCon是一个由社区组织、服务于社区的大会。因为投入了大量的精力,力争能让社区中的领头人就最重要的话题分享最精彩的内容,所以大会拥有高质量的会议体验。QCon的初衷就是要有一定的技术含量,关注企业应用,符合技术团队领导者、架构师与项目经理的需求。

   

1. 我是Charles Humble,在我身边的是Juergen Hoeller,Spring Framework的项目负责人。Juergen,我想先从Spring 3.1的一些特性开始这次采访。你能跟我们谈谈Spring Cache吗?

缓存肯定是Spring 3.1中的主要特性,它有点历史,其实这算是一个长期的需求了。我们从很早之前就想做一个缓存抽象了,终于在Spring 3.1里找到了这个机会真正发布它。Spring Cache的想法并非简单地为缓存提供方做一个抽象,它更多地是和访问模式有关,应用程序与缓存的典型交互是通过一个Spring抽象来完成的,其中提供了缓存管理器与缓存抽象、典型布局、(支持)键值对、缓存区等等概念。我们不仅仅提供抽象,还有声明式缓存,提供了注解和拦截机制。我们称其为缓存注解驱动,这和用于事务的TX注解驱动有点类似,你调用了一个方法,框架会拦截调用,检查缓存中是否有值,如果有则获取该值,而非调用方法,这些都是基于注解的,因此是一种注解驱动模型。

这才是我们真正想要的,缓存抽象是这些访问机制背后的东西。SPI的实际实现中只会自带Ehcache,作为参考实现;我们也依赖了一些外部项目,需要运行它们,因此为商业缓存提供方做了一些适配器,它们大多是商业软件。

我们引入缓存的部分原因是因为分布式缓存又一次成为了热门话题。当然,这并非是一个新兴领域,但随着云运动、云平台、平台即服务(Platforms as a Service)、分布式缓存再度成为话题。类似GemFire、Coherence这样的产品是我们所提供的模型的理想后端。而且我们以某种方式提供了这些产品的适配器,但不包含在Spring Framework项目本身里面。

   

2. 它是怎么与Spring Data搭配使用的?我想两者之间一定有一些重叠的地方,是吗?

是的,有关系那是很正常的事,因为它们都是针对同一领域的东西。缓存提供方某种形式上也被用作数据存储,特别是如今的分布式缓存为我们提供了持久化存储。Spring Data的目标是与更多不同的数据存储进行交互,比如Redis和MongoDB,我们为这类数据存储提供了Spring模板风格的访问类。因此,从某种形式上来说,两者是有关系的,但技术上又有不同,Spring Data所支持的更多是和数据库相似的访问模式,从用例上来说,如果更多地是在讨论面向缓存的数据访问模式,那么这时说的就是缓存抽象了。当然,还有很多其他的数据存储,它们不用键值模型,比如Neo4J,这是一个图数据库。

与这些数据源交互的方式有好几种。Spring Data并不是一个真正的抽象,它是一个针对那些数据存储的不同访问模型的支持包的集合。并非真的试图去抽象它们,而是试着把它们原生地暴露给基于Spring的应用程序。

   

3. 被搁置了很久的JCache JSR又被端了出来,有可能会被重新提上议程,这对Spring Cache会有影响吗?

是的;JCache JSR是我们所遵循的东西。某种程度上来说,我们正是在等它。但是目前我们只能说它在Spring 3.1里,还不是EE6的一部分。现在它还没有深入缓存领域,因此我们只能暂时自己提供缓存抽象,看起来实际是我们在提供完善的长期产品,就算JSR 107有了进展,那也很可能是在重复发明轮子。我并不认为老的JSR正在延着旧方向发展;它可能会成为EE7的一部分,提供新的缓存方法,我们会保证在我们的缓存抽象上一切都能完美集成,在缓存抽象之后的东西可能更重要一些,就像我们在其他领域做的那样。

我们将保证能很好地进行适配,在缓存方面我并没看到什么阻碍,因为从访问模式角度来看缓存还是很好理解的。我希望当JSR来临时,一切能自然地匹配起来;这可能是Spring 3.3要考虑的了。

   

4. 3.1中有没有关注过Spring Batch?

在引入新的核心功能时,我个人总是会考虑Spring Batch,因为Spring Batch对Spring有特殊的用法,传统的基于Spring的Web应用程序可能并不会这么用。Spring中的任务执行器、任务调度器,所有的并发编程设施,针对Fork/Join框架等内容,其中的一些东西在Java 7中将得到扩展或某种程度的改造。对于这些东西,我们计划以某种形式来暴露它们,或在Spring Batch中加以利用,这是我目前的主要考虑。

我认为Spring Batch模型、编程配置模型都是很好理解和被广泛接受的。我看到很多潜在的可能,尤其是在Spring Batch里,可以充分利用Fork/Join这样的东西,暴露它,把自己的步骤模型转换过去。这是我们通常建立的关系。Spring Framework提供了核心功能,已经有了一些用例,一些其他的Spring项目,例如Spring Integration和Spring Batch,使用这些功能;把它们集成进来。我希望基于Spring 3.1的Spring Integration和Spring Batch的版本能在Spring Framework 3.1发布后早日问世。

   

5. 刚才你提到了Fork/Join,就Spring来说,对Java 7里其他的特性有感兴趣的么?

有不少,我觉得Fork/Join可能是最重要的,它带来的影响最大,因为它是种编程模型、用户级功能,人们要去改造、重新考虑他们实现自己算法的方式。还有些其他东西,例如try-with-resources类和autocloseable接口。我们正在考虑使用这些东西,或者是以某种形式针对一些Spring类暴露它们,这样就能提供可以同try-with-resources类协作的框架类了。还有些别的正在考虑中的东西,比如JDBC 4.1,但那不是主要的,我们会保证我们的JDBC适配器(我们提供的JDBC装饰器)能用于JDBC 4.1。因此我们将做一次全面的Java 7升级,就我的使用经验来看,我相信Fork/Join框架和try-with-resources会是用户关注的东西。

还有一个我很想在Java 7中看到的东西,就是日期/时间API,不幸的是它并没有正式出现在Java 7中。我希望它能包含在Java 8里,同时再提供一个独立的版本,因为这真是个好东西;Java.util.Date和相关的代码需要有人关爱,需要一些竞争,需要一些改造,而日期/时间API就是一个好的开端。一旦它发布了,我们会立即把它纳入Spring的编程模型中,就好比Bean Validation和JSR 303(这是同一类东西);我们立刻就支持它了。 暂时我们还是不得不绑上Joda-Time,即使是在Java 7上。

   

6. 你们还增加了对话(conversation)支持,我猜这和CDI或Seam很类似。在Spring里我可以在什么地方使用它呢?

对话,从历史上来看,是与Web Flow相关联的。因此,我们当然在Spring Web Flow里有导航模型和与之相关的对话模型,基本是由流程导航模型强势驱动的,我们在Spring 3.1中增加对话的部分原因就是为了简化Web Flow:相比可能的实际代码要有更多的动机。其他的一些影响来自JSF,JSF里有多个对话扩展:例如MyFaces Orchestra;还有一些不这么有名的;当然还有CDI里的那个,也是面向JSF的。我们尝试在这个领域里提供一些公用的东西,所以说Spring 3.1并不是要深入Web Flow领域,而是想提供基础对话管理机制,Web Flow可能会用到它,可能会代理给它,不仅仅是一个基础的对话存储抽象,有当前对话的概念,并进行管理。

就我们目前所理解到的东西,这就是我们真正需要提供的一切了,有了它我们就能有一定的互操作性,一个Web Flow管理的对话可能会与JSF对话或在Spring MVC中使用的对话的互操作性。从用例来看,会有Web Flow,会有JSF对话(这是很好理解的),从Spring MVC的视角来看,我们有一个会话属性存储机制,管理Spring MVC中的会话属性,我们还想以某种形式将它和更灵活的对话管理方案集成起来。我们目前正在着手进行定稿。

最重要的用例是人们希望做到窗口隔离。对Spring MVC而言,这可能是该领域中最大的一个要求或请求。会话属性默认是存储在HTTP会话中的,这就意味着所有窗口、所有标签页都在同一个浏览器存储中,基本就是与同一个会话交互。如果你在多个标签页中打开了同一个表单,它们都会共享相同的会话属性,它们会把自己的数据存储到里面。因此,针对多个独立的表单对话,在多个窗口标签页里要有一层隔离,那是Spring MVC用户发起的一个请求,而且这也是我们日程中的一部分,即试图针对这个特别的问题提供一流解决方案。所以说,真的是这么多东西凑在一起形成了Spring 3.1里的对话管理功能。

这有点像CDI和Seam里的对话,但仅限于三个视角中的一个。MVC视角和Web Flow视角非常独立,从很多方面来看都有很多不同之处。所以我们会发现,我们的任务是去发现并标识出公共的部分,把它纳入Spring的核心中来。

   

7. 既然你提到了CDI,你对它有什么看法?

我一直在密切关注CDI规范的发展,它的历史很有意思。它开始时和我们最终得到的东西很不一样,它原来的目标是开发一个对话作用域(conversation scope),最原始的任务是开发一个介于JSF和EJB3之间的对话域,全局JSF-EJB3集成也是其中之一。但最终它却变成了一个相当丰富的依赖注入模型。其中不乏有趣的想法,有一些和Spring中的做法不太一样,尤其是Spring 2.5的。当然,这里也有一些公共的东西,Spring 3.0和3.1同时都支持JSR 330定义的公共依赖注入注解,CDI容器也支持这套注解:@inject、@qualifier、提供方接口,还有依赖注入模型的核心部分。

当然,在此之上CDI还添加了一些东西:事件模型、一个特殊的作用域模型(soping model)。从设计上来说其中有些东西与Spring不同,但我要说的是如果你对Spring、依赖注入和Bean作用域有比较深入的理解,这些东西都能被很好地转换到CDI上,反之亦然。因此在两者间迁移应该不会太困难。它们只是选择了不同的设计方向,很自然地涉及了一些不同的设计权衡。我也有一些不太认同CDI的地方,但我肯定CDI的设计者对Srping的一些设计也不太认同,所以我觉得这很正常。尽管我们我们关注CDI,但目前还没有进一步的计划。

我们正紧跟JSR 330的发展,看起来针对Java EE7会有一个核心依赖注入规范的版本,起码是1.1版,大家可以期待Spring提供一个支持该版本的实现。

   

8. 我想Java EE6与Spring 3几乎是同时发布。

只是相差几天而已。

   

9. 那个标准对Spring有什么影响,Spring又是如何兼容它的?

我们关注的不仅仅是CDI,而是整个Java EE 6规范,在Java EE6规范发布后的几天里Spring 3.0就发布了GA版本并不是一个巧合。我们密切关注着几个规范的演进,其中包括JPA 2.0、JSF 2.0,当然还有JSR 330和JSR 303(Bean Validation Specification)。就Spring而言,这四个东西是EE6里最有趣的部分,它们实际上非常独立。我是说JSR 303有独立的实现,可以很好地放入各种应用程序中,JSR 330依赖注入注解也是如此,JPA 2.0 Provider在很多环境里也很有用。这就是我们关心它们,并在这些规范定稿后(实际上是在它们发布生产质量的参考实现之前)就立刻支持它们的部分原因。

EE6里的其他部分,例如Servlet 3.0,我们只是测了一下,还没有专门去支持它们。在Spring 3.1中我们正在缩小与EE6的差距,Servlet 3.0支持是其特性之一,尤其是会支持Servlet 3.0的配置模型。这是一种在Servlet 3.0中替代web.xml驱动启动(Servlet容器初始化模型)的方式,它和Spring的基于Java的配置模型搭配起来非常合适。因此,我们正尝试为结合使用Spring 3.1的Servlet 3.0用户提供无缝体验,基本是非XML配置的体验,这真的是一个很好的组合。除此之外,Java EE6里还有JAX-RS和一些其他的有趣的规范,尽管Spring本身并没有特别去支持JAX-RS,但它们却能很好地与Spring协同使用。

原因很简单:所有主流的JAX-RS提供方都自己提供了Spring支持。因此,你将会有Jersey的Spring支持,有RESTEasy的Spring支持。要在JAX-RS世界里做一个好公民,在Spring Framework方面并没什么要做的。所以我说Spring 3.x有很好的Java EE6背景,不仅独立使用了多个EE6的规范,还能在Java EE6服务器上运行完整的Spring应用程序,就Spring而言这相当于默认把所有的规范和一些提供方打了个包。你有了一个JPA 2.0提供方、一个JSR 303提供方以及一个Servlet 3.0容器。

这是一个很好的基础,Spring 3编程模型可以构建在此基础之上。我们就是这么认为的,以GlassFish为例,GlassFish 3.0、3.1对基于Spring的应用程序而言是个很棒的服务器,我们正是用它来做测试的。我们甚至还有专门的GlassFish加载时织入支持(GlassFish load time support),它真的很适合基于Spring的应用程序。

   

10. 大家都在讨论Java EE7中的一个东西,即多租户(multi-tenancy)问题,在多个不同环境(可以是一台App Server,或者是一个私有云,或者是公有云)上运行同一个应用程序,Spring中是否有这个问题?

在我们的理解中,EE7规范会处理多租户,在我看来,Java EE世界里的应用程序之间本身就有很好的隔离,云平台(比如我们目前拥有的Platforms as a Service:Google App Engine、Amazon Elastic BeanStalk)上也是如此;它们使用的war部署单元,基本都是在运行时围绕war文件管理着一个独立的容器,这看上去已经把它们隔得很开了。就这点来说,基于Spring的应用程序在war文件里真的可以看成是高级公民了。从多个方面来看,Spring是基于war部署当仁不让的选择,认识到了这一点之后,我们就没什么必要参与到任何Servlet容器会提供的隔离模型中去了。

如果有什么事是我们可以做的,那么我们一定会做的,例如应用程序可能会为容器提供一些配置上下文,用于标识与其他应用程序的某类隔离级别。不过Java EE 7规范先要在这方面发布一份更详细的模型。

   

11. 在我的印象中,Spring不太愿意参与标准化过程。通常你们是遵循标准,甚至是紧跟标准,但我却没看到Spring在标准化过程中有多少投入。不知道我这么说是否合理?

有这样一个印象也是很正常的,尽管在历史上和JCP内部,事情其实并非如此。从具体参与的角度来说,我们的确参与了JSR 330。虽然JSR 330主要是由Bob Lee驱动的,与Bob Lee一起,我们也是该规范的合作领导者,但严格说来,Bob Lee是主要领导。我们还在关注几个其他的规范,关注专家组里的成员,比方说JSF 2.0。我想我们在设计影响力上可能比不上其他人,因为JSF也有几个领导者,他们在推动规范向前发展,专家组里的大多数人会听从他们的意见;JSF 2.1和2.2的情况也差不多。我们正在积极参与其中,讨论以何种方式为JSF 2.2做些具体的工作。

但以我来看,我们要在他们开发时就遵循规范,从早期阶段就开始关注规范。我们并不是非要去影响他们;我们只要确保这些东西和Spring的编程模型放一起能玩得转就可以了。这才是我们最重要的任务。在一些特定的领域里,我个人很关心标准化:约束注解(constraint annotations),我觉得它们真的是深入到了领域模型的核心之中,这些东西应该被标准化;依赖注入,采用增加注入(inject)和限定词(qualifier)的形式,这很适合标准化。如果让我来选择典型(stereotype)模型,好比Spring中添加了组件和自定义典型,如果JSR 330或JSR 250有一个灵活的核心典型模型方案,我会立刻使用它们的。

我个人在标准化方面对一些更具体的东西很感兴趣,但总的来说,Spring提供了自己的编程模型和配置模型,可以自给自足。因此Spring可以选择性地增加标准化的部分,但我认为它自身不应该标准化。它更应该成为所有这些围绕它的标准的好公民,成为各标准化部件之间的粘合剂。这才是目前的Spring,这才是它的定位。

   

12. 你有Spring 3.1和Spring 3.2的时间表吗?

大致的日期是有的;对于Spring 3.1来说有确切的日期。我们正在努力开发milestone 2版本,就计划了两个里程碑版本,然后就是RC1,milestone 2是4月发布,RC1是5月底,GA是在6月底。我希望我们能按着这个计划进行,这不仅取决于我们,一旦发布了RC版本,就是由用户社区来告诉我们在GA前是否需要更多的RC版本。因此说Spring 3.1大致会在Q2底发布,Spring 3.2会紧随其后,基本是2012年年初。这个动作比我们以前发布主要版本快多了。Java 7会在今年Q3发布,Spring 3.2受Java 7的影响很大,因为其中的主要特性就是Java 7支持。所以什么时候我们觉得从Spring方面来看Java 7的任务完成了,那就是我们发布Spring 3.2的时候。我觉得明年早些时候的机会会更好些。

我们也已经有了一些Java 8的想法。Java 7和Java 8被分开了。Java 8中有些东西是没来得及放入Java 7的,Java 8语言特性中的的许多设计已经很清楚了,基本是由JDK团队提交具体的提案,比如闭包会基于他们所谓的单一抽象方法类型来进行编译。所以我们已经把一些可能的设计影响和设计考虑纳入了Spring 3.1和3.2,基本已经做好了迎接Java 8语言增强的准备。这些都是超前的,因为在2012年底前Java 8都不会发布,也许2013年初会更实际一些;我们就是在为此做准备。这就是我们目前的计划。我很确定Spring 3.3最终会在Java EE 7、Java 8问世后不久发布。

通常我们只会提前12个月做具体计划。在Java领域中,Java行业的发展是非常快的,因此很难说哪些是要在一年里做考虑的。我们在发布计划上很灵活、很敏捷。我们真的是在倾听,大家告诉我们要发布什么,我们就力争在正确的时间发布它们,并不一定总要在规范定稿的时候,正确的时间通常是指大家开始采用某些规范的时候,他们真的开始使用某些参考实现的时候。Java 7的时机很好,大家实际会很快使用它。以Tomcat为例,让Tomcat 7运行在OpenJDK 7上就是一种很直接的从OpenJDK 6迁移过来的办法。因此我希望Java领域中至少有部分东西能很快升级到Java 7上。

这就是为什么我们会很快发布一个带Java 7支持的Spring 3.2版本,因为我们希望其被采用的过程至少能比以前好。你知道的,Java 5和Java 6花了好多年才在业内真的使用起来。我真心希望Java 7能很快成为主流。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT