Oracle的Java模块化系统保卫战

2017年企业新兴技术(ETE)大会上最为及时的演讲之一要算由Oracle JVM负责人Karen Kinnear呈献的“Java的未来:模块化及其他”。在她演讲之前的这段时间发生了很多事情,其中最为引人瞩目的就是5月8号针对JSR 376的投票事件。

Kinnear介绍了Java 9的目标,包括提升开发者效率和改进Java云API。在对Java 9相关的JEP进行了一番评述之后,她开始专注于Java平台模块化系统(JPMS)的话题。JPMS也就是Jigsaw项目JSR 376

Kinnear向参会人员问了三个有关模块化的问题。

  • 模块遗漏问题。 
    • 模块系统在构建模块图时会检测遗漏的模块。
  • 冲突问题。 
    • 在构建模块图时包的冲突问题也会被检测到。
  • 变更内部API是否安全? 
    • 模块系统可以确保无法从模块外部访问内部的API。

Kinnear说,模块可以被集成到已有的应用程序里,她还演示了包与模块之间如何进行交互,解释了模块路径和类路径之间的区别。她还向开发者介绍了如何迁移到Java 9,特别是如何在迁移过程中保持向后兼容。

Oracle Java平台组的首席架构师Mark Reinhold在2016年3月份的白皮书中描述了JPMS的目标。

  • 可靠的配置 
    • 使用声明式的程序组件依赖机制代替脆弱且容易出错的类路径机制。
  • 强封装 
    • 组件可以声明自己的哪些公共类型是可以被其他组件访问哪些是不能被访问的。

社区的反应

Red Hat的JBoss架构副主席Scott Stark表达了他对JPMS存在的一些疑问,Red Hat认为这些问题是影响JPMS无法达成JSR提交目标的主要因素。Stark说:

Jigsaw是一个全新的模块化系统,它可以很好地应用在Java上,但并没有在生产环境里那些基于JVM的真实应用上大规模尝试应用JPMS。很多应用程序可能无法使用Jigsaw,或者需要进行重大的重构才可以。

IBM和Red Hat公开表示他们不会为当前的JPMS投赞成票

尽管没有达成一致意见,Reinhold仍然提交了JSR 376公开预览版,并声明“这对于广大的Java生态圈来说是最有益的,我们因此可以达成切实的目标”。在投票当天,他还向执行委员会(EC)提交了一封公开信,呼吁他们能够为JSR 376投赞成票。不过,最终JSR 376仍然没能通过投票。

投票之后

Twitter的JVM和GC工程师Tony Printezis解释了Twitter投反对票的原因

我们的主要疑问在于,JPMS有可能会颠覆开发者,但却未能给他们带来直接的好处。我们担心因此会阻碍这项技术的大规模采用。我们希望JPMS能够对最初的目标做更全面的调整,从而真正地解决开发者的痛点。比如,非公开包名称冲突就与当前JSR“不互相干扰”和“强封装”的目标不一致。而如果模块能够更加彻底地分离,那么就可以通过把包隐藏在模块内部来支持相同包的多个复本同时存在。如此直观的好处简化了开发人员模块化代码的工作,也因此能够加速JPMS的采用速度。

在与InfoWorld的一次访谈中,Reinhold尝试着澄清人们对JPMS的误解。关于人们反对无法在Java中使用Maven这一问题上,Reinhold说,这不是真的,“Maven可以在Java 9里使用”。不过他承认,Maven的插件可能无法正常运行,包括Surefire测试插件

Reinhold确认了开发者最喜欢的一些库、框架和工具可能无法在Java 9中使用,这是因为当下的一些因素造成的,不过他说在正式发布时可能可以解决这些问题。他指出,这些项目的维护者已经在使用Java 9抢先版,所以他们会为这些项目做好支持Java 9的准备。这也就是为什么一些项目已经可以使用Java 9,如Spring BootHibernate Validator

很多开发团队认为,在他们将所有代码、框架和库模块化之前就不能使用Java 9。Reinhold说这也是不对的。

开发人员可以在Java 9里继续使用类路径,不过因为Java 9有了模块机制,所以开发人员就不再需要类路径了。

伦敦Java社区共同创始人及jClarity CEO Martijn VerburgInfoQ交流了他对JSR 376投票的看法。在谈到JVM模块化的好处时,他说:

它为Java代码提供了更多的安全性;它隐藏了很多内部API或者不应该暴露给开发人员的API;不过需要为那些被隐藏的功能提供安全的替代方案。Java的运行时将变得更小,因为运行时被拆分成更小的模块。Java 9将提供jlink工具,用于将应用程序部署在更小的运行时上,只安装必要的组件。服务器端的应用程序就不需要把客户端的GUI(如AWT何Swing)也包含在内。这样,Java可以启动得更快,可以在更小的设备上运行应用,在云端的部署也会更快。

IBM的高级技术研究员Tim Ellison最近表达了他对如何在JSR 376上达成共识的看法。他说:

我们希望看到修订过的规范重新呈现给JCP执行委员会,也希望执行委员会能够支持专家组的结论。IBM关心的是企业应用在迁移到Java 9时的兼容性问题。升级到Java 9对迁移有重大的影响,而JPMS的默认行为在这方面会提供很大的帮助。

JSR 376即将进入到终稿阶段。在定稿之前可能还有一些小幅度的改动,不过整个过程充分展示了JCP致力于为Java提供更加强大的语言特性。感谢Oracle一直在主导这个规范,以及专家组在这个里程碑上所投入的大量精力。

Reinhold最近针对Java 9的GA版本发布日期提出了一个新的提议。他说:

为了迎接各种可能的结果,我建议保持6月22号的JDK 9初始候选版本发布日期不变,不过将GA版本的发布日期向后延期,为通过JCP流程争取更多的时间。我提议将GA版本的发布日期向后延期8周,从7月27号调整为9月21号。

JSR 376的下一个投票日期是周一,也就是2017年6月26号。

参考资料

编辑后记

Michael Redlich是ETE的积极参与者,他从2008年开始作为ETE的参会者和演讲者,2013年成为ETE指导委员会的成员。

查看英文原文Oracle Defends the Java Module System

该文章由WP-AutoPost插件自动采集发布

原文地址:http://www.infoq.com/cn/news/2017/06/oracle-defends-jpms?utm_source=news_about_java&utm_medium=link&utm_campaign=java

InfoQ在ETE大会上对Android工程师Jake Wharton的采访

ETE 2017(用于企业的新兴技术,Emerging Technologies for the Enterprise)大会上,Square的Android工程师Jake Wharton作了名为“使用RxJava管理响应式世界”(Managing the Reactive World with RxJava)的报告。

报告的中心主题是“除非整个系统可以同步地建模,否则一旦存在一个异步数据源,就会破坏整个指令式编程”。Wharton解释说,一旦引入了异步数据源,指令式编程方式就开始坍塌。状态管理的重担是落在开发人员身上的,而非落在可简化开发的软件库上。他在报告中使用了RxJava例子展示了这一理念。他比较了基础源(Source)Observable<T>Flowable<T>、这些源的观察(Observe)方法,以及一些可操作数据或发射(Emission)的操作符。在报告最后进行总结时,他简要地探讨了Java 9和JEP 266中新引入的“Flow”类,其中封装了支持响应式“发布-订阅”框架的接口。

在ETE大会上,Wharton向InfoQ介绍了他在Square的工作情况,以及他对响应式系统、RxJava和Kotlin的理解。

InfoQ:您已Square工作多久了?当前职位是什么?

Wharton:我在Square工作了五年。

我参与Square Cash应用项目。它是一个P2P支付应用,可实现向朋友或家庭的转账。我供职于其中的Android Mobile团队,该团队主要构建Android App。相比于名气更大的Square Register产品,Android Mobile是一个相对较小的团队,只有三个人。我的主要工作聚焦于架构、基础设施和支持应用的软件库,目标是支持团队中的另两位开发人员高速地构建新的显示和特性,并解决如何构建的问题,以避免在App中陷入或碰上扩展性或序列化问题。我的目标是解决每一处枯燥的工作,使得产品本身总能以很快的速度推进。

InfoQ:很多人是通过零售终端系统(POS,Point-Of-Sale)业务而熟悉Square的。Square还提供哪些产品或服务?

Wharton:除了Square Cash,POS基本上只是我们所有产品的冰山一角。Square聚焦于商家,提供运行业务相关的所有产品。我们所瞄准的是使用POS App进行销售的各种个体零售商,从适当规模的餐馆到多单位业务。这些用户的需求不仅是一个可以刷卡的App。就此我们还提供了一些衍生产品,例如雇员管理、安排预约和发票跟踪等。对于那些业务越做越大的用户,这些产品提供了辅助POS的功能。我们的理念是,如果当用户还是小型企业甚至是个体企业时就开始使用Square,那么随着用户业务的成长和扩大,他们会移动到线上、移动零售地点、具有多个零售网点、雇佣员工,以及更多事情,我们希望用户依然使用我们所提供的生态系统。因为我们正在提供所有适用的产品,并更紧密地集成在一起,力图为用户提供最好的业务管理体验,避免业务管理变成一项令人乏味和世俗的任务。我们正在尝试提供多种适合用户的产品。

InfoQ:与其它的POS系统相比,Square的产品具有哪些独特之处?

Wharton:现在每个人的口袋中都有一台计算机,我们已准备好迎接这一事实。对于用户在做的很多事情,我们都提供了可在移动电话上完成的功能,无论是使用App还是访问Web网站。我并非说我们的很多竞争者是传统的,而是说他们所构建的产品是用于十到十五年前的大型企业。这种做法在那个年代是合理的,因为人们并不会随身携带智能手机四处转悠。用户必须为这些软件厂商所提供的定制硬件支付大笔费用,而这些软件厂商却并没有提供深入用户业务的真正定制的、真正丰富的在线服务。Square是一个高度移动化并以数据为第一位的企业,力图为用户提供所有可能的功能,这可以通过用户已有的iPad,也可以通过当前已相对便宜的硬件实现。用户要开始采用移动端的支付业务,Square就会免费提供给用户一些硬件,无需用户支付任何费用。这样用户基本上无需任何投资就可以做到移动支付。由于Square降低了业务入门的门槛,并且实现了移动端优先以及数据第一位,使得所有业务在线提供给用户,用户可以通过这样的方式使用移动电话、电脑等日常用品控制业务,并获取对业务的洞察力。另一方面,Square面向的是一个传统上仍未得到开发的市场。银行及那些创建POS的企业所面向的是大型零售商店和大型连锁餐馆,这会为它们的投资带来很好的收益。但是还存在着整个尚未开发的零售商市场,其中包括小型的家庭经营商店、个人出售农产品以及手工艺制作者。这就是为什么你去其它地方购买咖啡时,会希望能看到Square的POS硬件,因为上面所说的市场中是只支付现金的。

InfoQ:RxJava 1.x和RxJava 2间的主要差别是什么?

Wharton:现在具有两个主要类型的响应式数据源,这是RxJava 1和RxJava 2间的最大差别。存在这两个类型的原因在于,其中一个类型允许背压(Back Pressure),而另一个则不允许背压。在RxJava 1中,每个响应式类型的可观察对象(Observable)将暴露背压(即提供可放缓的功能),但事实上并非每个源都喜欢这样。因此有时你试图去放缓一个响应式源,它将会抛出一个异常。在RxJava 2中分离了这两种类型,因此现在我们知道类型系统中存在一个具备被可放缓功能的源,而另一个源则不具备。另一个主要挑战是,现在已有多家企业共同努力去标准化响应式软件库的API,这被称为“Reactive Streams”。RxJava 2原生地实现了这些接口,并暴露自身为符合Reactive Streams的实现。这是一个改进软件库内部架构的机会,降低了一些在先前的RxJava 1架构中已发现的开销。因此RxJava 2更快,兼容性更好。现在类型系统对数据源的进一步行为提供了更多的保证。

InfoQ:除Netflix之外,还有哪些企业正在使用响应式系统?

Wharton:Netflix无疑是最大的响应式系统用户,正是由它联合发起了最初的RxJava 1实现,而且给出RxJava 1设计与实现的主要贡献者都曾供职于Netflix。据我所知,Lightbend也极大地推动了响应式。其Akka产品在传统上被认为是一个Actor系统,但是它同时也是Reactive Streams的一个兼容实现。除此以外,在ReactiveX网站还上列出了一些企业。在Andorid领域,响应式的确已在客户应用中被大量采用。当前各大企业在构建App时都使用了RxJava。在服务器端,由于使用了很多墨守成规的软件库,因此无法看到像在Android上那样的快速转变。

Netflix是响应式的最大使用者。其所构建的大量开源产品和软件库都是构建于RxJava之上的。Netflix具有大量的内容,并提供了大量的如何使用这一模式构建系统的博客帖子。因此Netflix无疑是我所看见的最大使用者。

InfoQ:您是怎么看待响应式编程和Reactive Streams?未来五年内RxJava将如何演化?

Wharton:当前在JVM端,Java 9引入了与Reactive Streams项目所创建接口兼容的接口。在我看来,由于Reactive Streams已是JDK的组成部分,它将会在服务器端得到更广泛的采用。当然,对于被称作“Flow”的新API,还应给出它的实现,因为当前尚未有这样的实现。它本质上只是一种JDK中的接口,而非一种具体的实现。因此,我们仍需要类似于RxJava和Spring的Project Reactor这样的软件库去实现它们。由于响应式已存在于JDK中,我们可能会看到大量这样的非常基础的服务器软件库(例如Spring和Netty)基于响应式构建自身的API,使得这些API以这种一致的Reactive Streams方式暴露。此外,对于Android客户端,响应式是一种资源受限的环境,并且看上去RxJava 2无疑是手边最好用的,因为未来的RxJava和Project Reactor版本非常有可能是依赖于Java 9的。至少最近五年内,Java 9将会在Android上大展宏图,并且实际上处于野生发展状态,我们可以开始使用它。可能除了软件库开始采用RxJava 2之外,我们将看不到更多的整体进展。

InfoQ:对于那些学习响应式编程和RxJava的开发人员,您推荐的第一步是什么?

Wharton:事实上,新版本的Spring已原生地实现了Reactive Streams,其大量文档已经更新,文档中给出了如何使用Spring API响应式地构建服务器。对于服务器开发人员,这是个很好的出发点,从中可以看到一些构建和操作工作的实际实现。对于客户端和Android开发人员,现已有大量的可用内容,其中可以查看业内人士的演讲,查阅App的开源例子。这的确是最好的出发点,并且应是初学者确实必须去点击查看的。初学者应尽可能地观看更多的幻灯,尽可能地读取更多的文档,直到他们开始实践,了解响应式背后的机制,并掌握组件间相互交互的方式。一旦开发人员能从传统的命令式编程转向基于推送的响应式方式,并且真正地开始以新方式思考问题,就会得到一种“不过如此”的感觉。但是在此之前,如果没有尝试去构建并操作这些API,我们的确只能局限于自己的理解之中。

推荐一两本可用的书。Netflix的最早期开发人员Ben Christensen做了大量RxJava的最初工作。他参与撰写了一本书,并于数月前出版面世了。书中提供了很多入门内容,有助于读者构建一种思考问题方式的框架。在我看来,有很多的文档资料都并未做到这一点。这本书值得一读。

InfoQ:您是否愿意向我们的读者介绍一下您自己、您的工作,或是其它一些我们没有提及的方面吗?

Wharton:在我看来,最有意思的莫过于看到Kotlin会得到更广泛采用。Kotlin实际上与响应式编程关联得很好,因为它允许对一个无论是否为Null的值建模,很显然这是一个经常发生的事情。Kotlin还具有大量与RxJava工作很好的语言原语。举个例子,它允许我们使用密封类(Sealed Classes)层级结构,这本质上是一个抽象类,而后是对类的多种实现,不再需要实现额外的子类。这是非常重要的,因为这将允许开发人员对一些类型建模,这些类型可具有来自于用户接口的事件,例如可以是点击了一个按钮,还可以是用户按下了键盘上的回车键。两者可以是同一类型的子类,Kotlin语言不仅允许开发人员使用简洁的语法定义这样的子类,并且提供了非常便于使用的when操作符。when操作符类似于Java中的switch,但是不同于switch之处在于when并非必须要给出一个默认的case语句,因为编译器可以证明这两个事件已经正在处理,并且将不存在其它具有该类型子类的事件。when也会实现类似于智能转换(cast)的功能。当执行对每个事件的case语句块时,它自动地将事件转换为这一类型。因此,对于所有事情必须流经同一管道的应用,如果要在这样的应用中构建Reactive Streams,倾向于使用单一类型,之后再使用子类型表示不同的数据位。在将Kotlin这一语言和RxJava或其它任何的响应式库混合一起时,让语言使开发人员回归依照句法定义类型,以及依照句法从开发人员自身的下一次回调中拉取回类型,这种做法无疑具有很大的好处。

InfoQ:看上去近期Kotlin的发展势头很好。

Wharton:正类似于我们在RxJava中所经历的,这是Android移动开发快速地引入了新技术的另一个实例。现在Kotlin更为成熟了,我们将会在服务器端开发和已有的软件库中更多地看到它。无论出于何种原因,这些软件库需要更多的时间去采用这类更新的语言和新软件库。因此,很高兴能看到Kotlin得到了更多的关注。此外,Kotlin非常关注自身的完全兼容性,并具有非常好的工具,这正是大量其它的JVM语言过去曾缺失的。

编者按:

自2008年以来,Michael Redlich一直是ETE大会的积极参与者,先期作为参会者和演讲者,近期自2013年以来,担任ETE大会指导委员会成员。

查看英文原文: Jake Wharton, Android Engineer at Square, Speaks to InfoQ at ETE

该文章由WP-AutoPost插件自动采集发布

原文地址:http://www.infoq.com/cn/news/2017/06/jake-wharton-speaks-to-infoq?utm_source=news_about_java&utm_medium=link&utm_campaign=java

InfoQ在新兴技术企业大会上对Lightbend企业架构师Kiki Carter的访谈

Kiki Carter,Lightbend企业架构师,在2017新兴技术企业大会(Emerging Technologies for the Enterprise,ETE)上发表了题为“Somm”Lagom: Building Systems That Age Like Wine的演讲。

“Somm”取自2012年的同名电影,电影讲述了四位美国侍酒师如何经过刻苦学习努力拼搏而通过“Master Sommelier”考试的故事。Carter用这个比喻来阐述软件应用应该如何像好酒一样持久。她介绍了企业开发人员在快速系统建立的新时代所面临的挑战。这些挑战包括:

  • 选择太多,陷入分析瘫痪状态
  • 难以衡量伸缩架构的完整性
  • 需要专家
  • 未预计到的复杂性或杂乱问题

她向我们介绍了Lagom,Lightbend“自定义”的微服务框架,该框架基于Akka框架和Play家族产品,并且介绍了Lagom如何解决当今企业所面临的挑战。Carter认为,“快速的变化通常意味着快速老化。”总的来说,她认为“为了与变化保持同样的步伐,并且在发展过程中保持架构的完整性,可以尝试使用能够在应用层面之上——也就是系统层面提供抽象的框架。”

InfoQ:你在Lightbend工作多久了?你目前负责的工作是什么?

Kiki Carter:我是去年七月加入Lightbend的,等夏天到了就满一年了。其实作为消费者和客户,我与Lightbend的合作已经有5年了。

我是Lightbend的一名架构师。我的大部分工作涉及到与更大的企业公司的互动,我要帮助他们更好地理解我们的技术,当我们有新的特色和软件产品时,要描述给他们,能够传播给他们,并且在那些公司内部增加我们软件的使用和采纳量。也许他们由小项目开始,看到了好处,然后想扩展,并且有了发展。我也会参与这些。让我们的团队能真正地在企业内部发展我们的响应式技术,这才是我工作的核心。

InfoQ:Bold Radius开发应用并且提供了关于Lightbend的咨询服务。OpsClarity开发了用于监控响应式系统的工具。这两家公司都是最近被Lightbend收购的。这一收购会怎样影响Lightbend为他们的客户提供服务的方式呢?

Carter:这是个很好的问题。我从Bold Radius开始讲吧。首先,收购过程中带来的事情之一在于它让我们能服务更多的客户。我们还在和其他具有同样业务的公司一起合作,包括提供专业服务。如你所知,我们不是一个咨询公司,我们要让公司不仅能使用我们的技术,更重要的是在它们的组织内部传播这些知识,这样我们就可以离开,然后让他们接管,从这一点上来看,收购确实为我们带来了好处。我们更关注让我们的客户和合作伙伴自己去完成所有的工作,而不是凡事亲力亲为,最后来一个草草的“交接”。

再说OpsClarity,这是另一个有趣的方面,我们能提供给客户更好的方法来可视化他们的远程监控。如你所知,监控异步和响应式应用以及分布式系统不是那么简单的事情。我们用Lightbend监测系统提供的远程监控至少在监控那些软件上真的帮到了人们。但是OpsClarity所带来的,是这种监控的另一个层面,它通过给人们提供一些很棒的可视化工具,让人们对他们的系统有一个很好的鸟瞰视图。OpsClarity内建了可视化能力,以及能够用于检测异常的人工智能。我们将它的监控系统进行进一步开发,让企业开发团队真的从中受益,并且以一种更智能的方式去使用它。

InfoQ:微服务在过去几年一直是一个很有意思的话题。根据2016年度企业发展趋势报告,各种组织在以下几种情况的分布很平均:(a)在生产环境使用微服务,(b)正在考虑使用微服务,(c)在沙箱环境试验微服务,(d)对微服务完全没有兴趣。还有不少针对使用微服务的开发者的警告标语,包括“微服务的七宗罪”。这传达出的信息似乎是“谨慎使用微服务”。针对这些顾虑,Lightbend有没有什么能做的呢?

Carter:当然,而且我觉得“谨慎使用微服务”这句话说的没错。在人们使用微服务时,如果不够谨慎,那么在行业生产中会造成巨大的反作用,如果没有正确使用,你会经历混乱,然后退缩,并且抗拒改变。但是,我们需要注意的是,我们需要一个能够在系统构建层面提供抽象的框架,用于封装架构最佳实践。所以,在构建微服务时遇到的错误或让你头疼的地方,推荐你使用我们的框架Lagom。Lagom是专为微服务构建的,我们对最佳实践、设计模式、架构原则,甚至是用到的底层技术和工具都进行了编码。只要使用Lagom的语法,几乎就能完全担保你正确编写微服务程序。这就是Lagom的魅力所在。它能解决技术问题,虽然它是在其他应用、框架、库以及工具上的一个抽象,Lagom将它们集成以让你用一种便捷的方式解决这些问题,即在保持架构完整性的同时,能够传递不仅仅是技术资产,同时也包括与你的系统设计有关的东西。这其实是Lagom的设计原则——确保你正确使用微服务,并且努力帮你避免混乱。

InfoQ:你认为应该怎样使用微服务?

Carter:我认为微服务的用途在于分解一个单体,但其目的不是在于分解一个单体,而是为了能让你更快的向客户和用户实现交付。它们需要更快的交付功能,能够让你的系统容错性更强,具备隔离性,以及能让你的系统随时间变得更强大,随时间发展,以及在系统的寿命周期内变得更加成熟。现在,改变发生的太快,所以快速改变系统,快速构建系统,以及修改它的能力已经成了使用微服务、以及用一致的方式管理微服务者必须注意的一个领域,它能帮助你的系统优雅地走向成熟。

InfoQ:关于你所说的分解一个单体,可以理解为应该使用微服务来开始开发一个新应用吗?

Carter:是的,但是你应该重新使用你的单体系统的某些部分。我不是说为了使用微服务,你就要毁掉整个系统然后重新开始。如果你使用Lagom,就不需要这样做。你可以按功能特性而不是按特定的技术模块来分解单体。如果你按特征分解,你只需要抽取目前的模块,进行组合,或许再加入一些其他东西,让特征自己变成一个新的服务。这样以来,新服务能够在你继续分解当前的单体时很好地进行互动。

InfoQ:你如何看待接下来的五年之内,SMACK 技术栈在软件开发中将变得更为重要这一说法?

Carter:这是个很好的问题,我认为它会更快地占据主导地位。接下来的五年,肯定会出现别的东西,但是至少现在,在当前数据经济的背景下,我认为SMACK 技术栈被大量使用的原因在于其数据的丰富性和进行大量计算的能力,并且速度很快。我们在Lightbend不说“大数据”,我们说“快数据”。这一概念在于它能够根据系统中现有的数据对系统进行深入了解,并在其老化之前快速地对其进行操作。现在,数据老化速度变得更快了。如果你需要快速地提供一个广告服务,或者是快速地做出,你需要能实时地做出这些决定。而SMACK技术栈能让你实现这个目的。在我看来,接下来的五年将是这个技术栈变革的五年。举个例子,当下我们认为占最大主导地位的是Kafka。也许在未来,分布式的、提交日志式系统的竞争中还会有其他对手。Uber的工程师开发了Cherami,跟Kafka类似,但并不是完全一样。我认为将来技术栈将是非常普遍的,因为人们已经将其组合在一起了。这些是领域内最好的,但我认为随着时间的变化它也会变化,而且你会看到更多的人们加入构建这个技术栈。我发现Spark一直以来都很活跃,但我也发现Flink和Beam的重要性一直在提升。我认为这个快速数据领域在未来一定会有所发展。在某个时刻,我们会看到解决问题的技术出现爆发式的增长。然后在之后某个时刻,又把它拉回到仅有少数技术的情况,说,“我们要以它们为标准”。

InfoQ:你如何看待响应式编程/响应式系统在未来五年的变化情况?

Carter:在这一领域我确实看到了一些明确的转变。有一件事,至少在响应式编程领域中,我们还需要缩小一些差距。很多时候,当人们谈论响应式编程时,他们关注的是异步通信,比如异步I/O和非阻塞通信。但是,当我们在Lightbend谈到响应式系统或响应式编程时,远远不止这些。Reactive Manifesto说明了人们是如何看待响应式的,响应式还需要处理容错和灵活性问题,而容错和灵活性是在构建系统时必须考虑的问题。当你仅仅进行响应式编程时,如果你在构建一个单体,或者一个响应性单体,或许你可以暂时忽略它,但是你一旦开始将系统组合起来,那些需要相互连接并协同工作的系统的容错能力、弹性和灵活性就是你必须考虑到的。我的意思是,比如说不依赖一个粗粒度灾难恢复类型的解决方案,这种方案一般仅使用容器、VM或一些东西来说明自己的弹性;而应该在依赖外部容器、或VM、或云平台之前就多多少少在应用层面具备弹性,这两者之间是有些细微差别的。

InfoQ:我在某处读到,自从Java8包含了函数式编程,用Scala构建的应用数量有所下降。关于应该选择Scala还是Java来构建应用,你对开发者有什么建议吗

Carter:其实Java8的发布不一定是人们越来越少地使用Scala的原因。同一时间里还有别的事情在发生。也许那些用Scala的人们决定试试Go,或更多地开始使用JavaScript框架。这几个事情之间不一定有联系。我认为,这个领域的很多公司一直在推动lambda函数式编程,他们已经来到了这个领域,并且给人们提供了尝试使用熟悉语言的空间。

如果有人让我在Java和Scala之间选择一个,选择结果应该跟你的商业目标有更紧密的关系。你公司的目标是什么?你团队的目标是什么?商业目标是什么?比如说,如果你的工作中有大量数据,或者你工作的环境要求真实数据的连贯性,你应该使用Spark。在Scala中使用不可变结构是很自然的一件事。这差不多是默认的。而使用java,你必须通过不同的方式来保持数据结构不变性。Java或许可以给你像lambda这样的东西,但它不能真的保证你能在没有任何副作用、没有非不变性数据结构的情况下,获得函数式编程的全部特性。如果你的开发团队已经习惯于使用命令式编程,或习惯于转换对象,而不是创造对象,这基本已经是人们使用Java的一种方式的范式转换。如果你不想落后,就应该以一种函数式的方式来使用Java,而你并不需要去了解Java编程习惯的变化。而如果你在使用Scala,那么你就已经是在那样做了。这确实取决于你的目标是什么。如果你真的想建立一个高度并发并具有良好数据完整性的系统,我会建议你去研究一下将不变性作为关键特性的语言。

这只是一个例子。但是,我会列出一系列人们会优先考虑的事情,甚至包括他们的最终目标。投资总是没坏处的,即使你在培训或学习上投资,或投资于你的最终目标。如果你投资学习Scala是因为它能帮助你更轻松地实现特殊的模式,那么这是一个好的投资。但如果说已经知道了Java,而且你设计应用时实现那些模式很困难,那你就需要考虑一下这个投资是不是值得了。

InfoQ:有意思。而且有趣的是这两个语言都可以编译成字节码在JVM上运行。

Carter:如果真的选择不了,那就做你觉得最舒服的事吧。不要封闭思想,对于系统的变化要持一种开放心态,因为Scala和Java像你所说的都可以编译成字节码在JVM上运行。它们的伟大之处,在于你可以朝着某个方向开始,然后随时进行改变。它们都具有良好的互操作性,所以你不会在字节码层面上丢失任何东西。

InfoQ:关于你自己还有什么是想让我们的读者了解的吗?比如你的作品,或者我错过的任何其他内容?

Carter:我喜欢旅游,而且去了很多国家。我喜欢在鸟瞰和跳伞的视角来看风景,但我有恐高症。我会去做我害怕的事情,是因为没有别的办法可以达到我的目的。除了跳伞,我没有别的方式能看到我喜欢的美丽的鸟瞰图,所以即使我恐高,也不能阻止我去玩跳伞。有意思的是,我是在和架构组织一起工作的时候发现这一点的,他们已经进入了“拒绝变化”的模式。成功没有捷径,你必须自己去尝试。

除了这些,我也喜欢社会工作。那是我生活的另一个方面。我喜欢参与阻止人口贩运组织的工作。我和救助组织一起帮忙救助那些被家庭卖掉或者被绑架的女孩。这是我的另一种激情。我一直在尝试研究技术和我们能构建的东西的交互作用,希望能为我们解决那些问题。

查看英文原文Kiki Carter, Enterprise Architect at Lightbend, Speaks to InfoQ at ETE


感谢薛命灯对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

该文章由WP-AutoPost插件自动采集发布

原文地址:http://www.infoq.com/cn/news/2017/06/kiki-carter-speaks-to-infoq?utm_source=news_about_java&utm_medium=link&utm_campaign=java

Java 9正式版有可能被推迟到9月21号发布

Oracle Java Platform Group首席架构师Mark Reinhold在五月份的一系列专家组电话会议中建议将Java 9的正式发布日期向后延期8周,也就是在9月21号发布(既定的发布日期为7月27号)。

据Reinhold透露,建议延期发布是为了给JSR 376争取更多的时间,如果在新一轮的投票中能够获得通过,那么Jigsaw就在Java 9中与大家见面。

JSR 376在之前的投票中没能获得通过(10票赞成,13票反对)。不过,后来他在OpenJDK邮件组里写道,没有通过投票并非意味着JSR 376就这样结束了,

也并非意味着委员会拒绝了Jigsaw。委员会只是提出了一些JSR 376专家组需要解决的问题。根据JCP的规则,专家组有30天的时间,也就是在6月7号之前再次提交修改过的版本进行第二轮投票,整个过程要在6月26号前结束。

Tomitribe的创始人兼CEO David Blevins也是投反对票的委员会成员之一。他认为,第一轮投反对票的委员会成员急切地希望看到他们提出的问题能够得到妥善解决,因为他们要在30天内进行第二次投票。虽然30天之后可能得到的是一个带有条件的通过票,不过Blevins对未来的情况持乐观的态度。他说:

尽管投反对票看起来是在拒绝,但我们坚信,对于一个JSR来说,这样的投票是为了达成更高层次的共识,虽然在时间上有一定压力。

在电话会议中,Reinhold建议6月22号的候选版本可以如期发布,但是希望正式版本可以延期到9月21号,从而为第二轮投票争取更多时间。如果在6月6号之前没有人提出异议,或者有人提出异议,但是如果能够得到圆满的解答,那么根据JEP 2.0流程,新的正式版发布日期就是9月21号了。


感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

该文章由WP-AutoPost插件自动采集发布

原文地址:http://www.infoq.com/cn/news/2017/06/Java-9-delayed-September-21st?utm_source=news_about_java&utm_medium=link&utm_campaign=java

npm 5.0普遍提升了性能

npm公司发布了其软件包管理工具npm 5.0版,这为公司多年的规划和累月的编码工作划上了一个句号。npm 5提升了性能,使其保持了对同类软件的竞争力。

Npm公司通过博客帖子宣布新的软件包管理工具发布,并称npm 5是“一次相当大的进步,显著地改进了几乎所有常见情况下的性能”。该发布并非仅是给出了新的主版本号,而主要是提供了一些新的特性和突破性改进。

据博客帖子介绍,npm 5中的一个重大改进是针对缓存的性能和行为,例如对离线行为的改进。现在npm会在机器离线时使用本地缓存,而不是去反复地尝试访问网络。开发人员可以通过设置--prefer-offline--prefer-online等选项定制缓存的使用方式。

但是这一重大改进将会导致全部已有的缓存失效,开发人员需要重新下载软件包。因此应确保在升级npm时具有高速的网络连接。

npm 5还提供了其它的一些新特性,其中最显著的改进是--save成为了默认行为。以前,要将完成安装的软件包保存在package.json文件中,开发人员需要发布命令:

npm install --save

虽然开发人员肯定有意向去执行软件包的保存行为,但是实际在命令执行时还是需要做双向确认(Opt-in)。在npm 5中,即使不明确指定该标识,软件包也会保存到package.json中。但麻烦的一面是,如果开发人员不想保存该软件包,需要在命令中明确指定--no-save标识。

在社区中,部分开发人员倾向于使用Yarn软件包管理工具,它是另一个很有前途的竞争者。Yarn的存在将促使npm更加努力,激发npm在性能上的改进。HackerNews用户chrisweekly写道:“感谢Yarn,帮助社区看到了真相(译者注:原文为“皇帝的新装”)。回想起来,很明显默认确定性构建的确是核心需求”。

npm公司CEO Isaac Schlueter指出,对npm 5的改进已经进行了很长的时间,并非是针对Yarn:

可以说,npm 5中的所有改进早在多年前就已做出了规划。鉴于已有大量用户依赖于npm工具,我们必须慎重对待重大更改。社区在Yarn的使用上给出了一个强烈信号,虽然这表明我们正走在正确的道路上,但从外部看上去,这一事件却仿佛是npm改进的“催化剂”。

无论改进是社区推动或是公司先行考虑到的,开发人员终将从中受益,能用上更快更好的工具。GitHub上提供了完整的npm 5发行说明。

查看英文原文: Npm 5.0 Boosts Common Sense Performance

该文章由WP-AutoPost插件自动采集发布

原文地址:http://www.infoq.com/cn/news/2017/06/npm-5-released?utm_source=news_about_java&utm_medium=link&utm_campaign=java