专栏名称: InfoQ
有内容的技术社区媒体。
目录
相关文章推荐
新浪科技  ·  【#上海二手房市场被激活#:#上海有房东直接 ... ·  19 小时前  
36氪  ·  女掌门上任后,海天涨了430亿 ·  昨天  
新浪科技  ·  【#全国高速公路车流量将超6500万辆次# ... ·  4 天前  
新浪科技  ·  【#理想汽车9月交付53709辆#,创单月交 ... ·  4 天前  
51好读  ›  专栏  ›  InfoQ

Q新闻:Gartner有关Java EE正在消亡的报告是否太言过其实了?Java类型推断将不再支持可变性规范……

InfoQ  · 公众号  · 科技媒体  · 2017-01-07 09:01

正文

编辑|小智
本周要闻:Gartner有关Java EE正在消亡的报告在某些方面受到了普遍质疑;Java类型推断将不再支持可变性规范;人工智能时代即将来临,2017~2020年的10个预测,畅想机器人的未来是怎样的?
Gartner有关Java EE正在消亡的报告是否太言过其实了?

Gartner发布了一份分析报告“应用程序平台市场指南”。在应用程序平台市场的“明显转变”部分,该报告指出,Java EE的“收入下滑”。这份报告迅速被Java EE的主要竞争对手Pivotal拿来发布在自己的网站上。

https://www.gartner.com/doc/3522917/market-guide-application-platforms

https://pivotal.io/gartner-market-guide-for-application-platforms

根据Garnter的报告:

数字业务方案需要应用程序平台提供新的特性和功能,而Java EE已经跟不上发展的步伐了。

负责应用程序基础设施现代化的应用程序负责人应该制定一种新的策略,以应对Java EE的衰退。

到2019年,在所有新增的业务应用程序中,部署在Java EE应用程序服务器中的将不足35%。

这份报告出自Ann Thomas和Aashish Gupta之手。Thomas是一位著名的Gartner分析师,从1988年开始一直从事学术研究及成果发表,而Gupta在2011年参加工作之初就是一名研究人员。这份报告排除了技术存在互补性的常见部署场景。

不出所料,这份报告在某些方面备受争议。前Oracle Java EE传教士Reza Rahman现在是Java EE Guardians的负责人,他告诉InfoQ:

很容易理解,这不是一份技术报告,而且,它似乎也不承认这样一个现实,那就是,如果有什么脱离了传统的三层模型和框架,那么它经常也是和Java EE共存于应用程序技术栈。

作家、技术专家兼咨询顾问Kito Mann做了进一步的说明:

Java EE并不是一个不可分割的单一整体;它是一个标准集,你可以选取你想使用的部分。即使是Pivotal的Spring Boot也是建立在一些核心的Java EE规范基础上,如Servlet、JPA和Bean Validation。

据Rahman介绍,数据驱动的Gartner报告与当时行业自主的调查报告相矛盾:

这大体上是一份“数据驱动”的报告,只是没有清楚地说明数据的质量、来源和数量。

所幸,我们确实有公开的数据可以反驳这份报告,我们对数据来源、质量和数量的了解更多一些。我们在Java EE Guardians的网站上策划了多项调查。

这里还有一项知名度较低但时间更近的调查,该调查列举了数据源,但没有说明数据量。

流行软件JRebel和XRebel的制造商ZeroTurnaround独立开展了自己的年度行业调查,他们的调查结果与Java EE Guardian的结论一致。

Rahman用一张图表汇总了结果,分版本说明了Java EE的增长。

Java Community Process成员、作家兼终身企业技术专家Josh Juneau告诉InfoQ:

我粗略地看了这份报告,并特别留意了说“Java EE衰退”的部分。显然,这份报告主要是面向这个市场中新来乍到的管理和开发团队;那些人对Java EE或者所有那些构建和部署企业级应用程序的可用选项不熟悉。该报告描绘了Java EE已过时的画面,但我认为,大部分社区成员和企业客户都会说,情况不是这样。

虽然在最近几个月/年里,构建企业级应用程序所采取的开发策略有一个明显的变化,但标准的Java EE应用程序在这个市场中仍然占有一席之地……而且,在将来许多年都是如此。也就是说,针对最新的发展趋势,通过不断地发布新的标准,Java EE会在这个市场中继续发挥作用。由于在整个2016年Oracle都非常的安静,Java EE的下一个版本存在不确定性(仍然存在)。不过,在2017年,Oracle将和社区一起推动Java EE的发展,并将继续为这个平台带来新的标准。如果你看下JSR邮件列表,就会发现,有关那些计划在Java EE 8中发布的规范的活动开始增加。

微服务和云的迅速发展也不可忽视。不过,那是两个领域,可能不会跟每个企业客户都有关系,会有许多客户永远不会将应用程序部署到云环境,而只是需要保留对企业应用程序的完全控制权。对于这些客户而言,当前的Java EE应用程序服务器方法最合适不过了。

使用应用程序服务器策略开发基于服务的应用程序也是可能的。微服务的“胖JAR”部署并不适合所有的人……在许多情况下都不适用。在开发任何企业级应用程序之前,都需要思考一下……为手头的任务选择最好的工具和策略。企业客户不应该仅仅因为云是一个趋势就选择微服务或者转向云,但那份报告反驳了这一观点。

最后,Java EE本来就不是一个为市场带来新技术和新策略的突破性、革命性平台。它是一个始终如一的标准环境,稳定、有效、可靠。Java EE基于已证实的标准,而微服务还没有达到一个可以标准化的点;这项开发技术还在发展之中。

但Juneau提醒说:

我认为,当Java EE 8发布的时候,它将为采用更为标准的方法构建微服务和云部署铺平道路。如果Java EE 9仍然可以按照预计发布时间发布,那么我相信,Java EE的目标是为部署微服务和基于云的应用程序提供一个稳定的标准环境,并继续为过去多年来那些已经基于可靠的Java EE技术栈构建的应用程序提供一个优秀的平台。也就是说,社区和JCP专家组需要保持警惕,跟上Java EE的步伐,确保它没有偏离目标。社区中有许多人已经知道诸如此类的报告,它们被起草用来说明Java EE正在衰退。这份报告利用了关键词和新策略……它并不适合需要一个可靠的标准方法的企业客户。

技术作家兼JavaOne明星工程师Ryan Cuprak告诉InfoQ:

这份报告令人疑惑——我不知道作者是否完全懂得他们正在比较/分析的技术。

这份报告的目的是通过Java EE攻击Oracle/IBM。注意,这篇文章并没有讨论成本节省、成功、恰当的项目类型、供应商锁定等问题。

Java EE很有价值,并将继续发展。大多数Java开发人员每天都使用Java EE,他们甚至都没有注意到。如果你正在使用JAX-RS实现一个微服务,那么你就使用了Java EE的组件。当一个平台被广泛地使用着,你不能说它正在消亡。你不能因为自己没有为一个小型的部门应用程序购买WebLogic,就说你没有从使用Java EE或其中的一部分获益。

Reza Rahman补充道:

显然,微服务和云在Java EE的规划中;对于加快Java EE 8和Java EE 9进度的承诺,那是Oracle JavaOne主题演讲的重点内容。

Java EE供应商也正在发挥他们的作用,既有像WildFly Swarm、Payara Micro这样的产品,也有像MicroProfile这样的联合方案。

至于平台比较,老实说,对于统治服务器端多年的Java,断言它在不远的将来就会失去在服务器端的统治地位并不可信。如果真是这样,那么Java EE和Spring真是目前为止仅有的两个可行选项吗?我已经提供了许多资源,我们已经证明,在服务器端Java中,Java EE仍将是使用最广泛的API集合。

除此以外,像Pivotal这样的公司已经争论了多年,但那些基本的事实那么多年来一直没变,而且,短时间内那似乎也不会有什么变化。至于收入,与Oracle通过Java EE相关产品获得的收入相比,Pivotal通过Spring获得的收入微乎其微。这还不算IBM、Red Hat及其他Java EE供应商的收入。如果将各种较小的、基于一个或多个Java EE API(如JMS提供程序)构建产品的供应商的收入都计算在内,那么Java EE的回报就更高了。

作为一个专注于开放标准的Java EE社区,我们仍然强大、充满生机,并不断发展。多年来,我们一直如此,这就是为什么我们可以得到Oracle的承诺。

InfoQ还同技术作家、演讲家和终身技术专家Alex Theedom进行了交谈:

因为重量级的膨胀而在为新兴应用程序架构提供支持时变得缓慢,Java EE的这个名声已经过时多年了。早在2009年,Adam Bien就展示了如何轻松地实现只有几KB的WAR部署。然后,在2013年,Arun Gupta展示了Java EE应用程序与Spring相比是如何显而易见的轻量级。Java EE开发高效且轻量级,经常只需要一个依赖;对其他框架而言,这可不容易。

每个人的日程上都有微服务和云,Oracle也明确地给出了承诺。企业Java的下一个版本(也就是Java EE 8,JSR366)包含了支持云基础设施和微服务的特性。除了Oracle的支持外,许多供应商和社区负责人也都在Java EE的发展进程中发挥了重要的作用,通过类似MicroProfile这样的方案,供应商、社区负责人和用户组一起合作,成功地将Java EE推进了微服务领域。

Java EE社区以及包括Payara、Tomitribe、IBM和Redhat在内的公司都在Java EE上投入了时间、精力和资源,以确保它向着社区希望的方向发展,而它也正在发展。有多少其他的生态系统从每天使用它的用户哪里获得了如此多的支持和贡献?

说Java EE过时、不重要及不适合原生云应用程序,说明他们对Java EE社区中正在发生的事情不了解,因为在我看来,它健康地活着,并且蓬勃地发展着。

JCP执行委员会成员Werner Keil提到了一批正在积极酝酿中的重要JSR,包括CDI、JSON-P和JAX-RS这三个MicropPofile用到的JSR。这些JSR让计划在2017年底发布的Java EE 8进入了微服务和云领域。为了在Servlet 4中支持HTTP 2,JSON-B接近完成,新的JSR 375(Java Security API)最近通过了更新投票,应该会有助于标准化现在仅以专有方式提供的Java EE安全机制。

Rahman还暗示说,这份报告得到了赞助,在同Pivotal交流时,他们否认了这种说法。

此外,Pivotal产品副总裁Ian Andrews告诉InfoQ:

关于Java EE以及传统应用服务器的使用下滑,业内有许多讨论。但是,真实的情况是原生云架构的崛起。Gartner每天都在全球范围内和CEO及CIO进行交谈,他们已经敏锐地意识到这种向原生云的重要转变,并建议他们的客户针对已有的应用程序组合推行一种现代化的策略。关于原生云架构的崛起,Gartner的独立研究和其他顶级研究公司(如Forrester和Redmonk)的调查结果类似。

在过去的3年中,我们在Pivotal见证了Spring Boot和Spring Cloud作为原生云应用程序构建块的迅速流行。Spring Boot 2016年11月单月下载量达1002万次,同期增长425%,这就是明证。我们希望帮助更多的组织使用我们的Spring技术,采用原生云架构实现关键应用程序的现代化。

本文翻译已获授权,原文链接:

https://www.infoq.com/news/2016/12/Gartner-downgrades-Java-EE

本文译者:谢丽

Java类型推断将不再支持可变性规范

Java类型推断是一项推荐的Java特性,允许开发人员使用var关键字代替显式的变量类型声明。最近的报道显示,由于社区内无法就区分可变和不可变变量的实现方式达成一致意见,Java类型推断将不再支持使用关键字区分可变的和不可变变量。提议的一些用来表示不可变变量的关键字包括val和let。为了避免对细枝末节的长期讨论,一些这样的例子将被排除以求简洁。尽管JEP并没有透露目标版本,Java 10可能会实现这些功能。

http://mail.openjdk.java.net/pipermail/platform-jep-discuss/2016-December/000066.html

为了完整地定义JEP 286的范围,甲骨文公司的Java语言架构师Brian Goetz在经过了一系列的提议和咨询之后了解到,实现局部变量类型推断(和避免显式声明变量类型的步骤)的新功能已达成足够共识,该功能应该使用关键词var。另外,社区还强调了他们希望使用和其它语言,如Scala、Kotlin或JavaScript,一样的方式来区分可变和不可变变量的类型推理。

然而,尽管大家赞同这是一个有用的功能,但是就如何实现该区分,没有一致的意见。var/val、var/let和(raw type)/var都有强烈的支持者和反对者。为了防止这种争论延迟类型推断的进展,该功能的主导者决定将范围缩小到局部变量的简单类型推断,不管可变性区别。尽管如此,使用稍长一点的构造final var,不可变的局部变量的类型仍然是可推断的。

var s = "hello"; // type of s is String
var keys = map.keySet(); // assuming map is of type Map, type 
                     // inferred for keys will be Set
final var MAX_COUNT = 100L; // MAX_COUNT will be immutable long

更新还用于提醒可推断的程度。一方面,只有初始化信息将用于推断变量的类型;这意味着在声明时未初始化的变量需要显式声明类型,它也有助于防止一些潜在的晦涩的错误(例如,代码深处的变量的类型推断错误)。另一方面,只有局部变量的类型是可推断的,不包括属性和方法,这是基于如下理解的。属性和方法是类的公共接口的一部分,因此需要由程序员明确定义。类型推断不起作用的其他情况是,暗示自身类型的初始化表达式,如:

List list = new LinkedList(); // type not indicated in
                                    // initialisation, but inferred
                                    // from variable declaration
var list = new LinkedList(); // error, impossible to infer a type for
                           // the contents of the list

Function f = s -> s.length(); // type of s and length
                                           // inferred from
                                           // declaration
var f = s -> s.length(); // error, type of s unknown, return type of
                     // length unknown

int[] array = {1, 2, 3}; // 1, 2, 3 interpreted as integers
var array = {1, 2, 3}; // error, poly expressions not supported
                   // (see below)

// Use Integer.valueOf(int)
Function intFunction = Integer::valueOf;

// Use Integer.valueOf(String)
Function stringFunction = Integer::valueOf; 

// error, ambiguous initialisation
var function = Integer::valueOf; // unable to know which overloaded
                             // version of valueOf should be used

目前还不清楚是否将支持上述的某些特定例子。如Goetz所说,“我们将初始化器看作一个独立表达式(standalone expression),通过获取它的类型得到变量的类型。然而,数组初始器与lambda和方法引用一样,是多变表达式(poly expression),所以被拒绝了。”多变表达式是Java 8中随着lambda引进的一个概念,与普通表达式的不同之处在于计算类型的方式。

对于普通表达式来说,可以通过在编译时检查表达式的内容获取类型;对于多变表达式,要计算类型,除此之外还需要目标类型(即被表达式赋值的变量的类型)。这意味着,多变表达式已经隐含了一些对自身的类型推断,因此很难甚至不可能推断多变表达式的类型。但是,有一些这类问题的场景似乎提供了足以推断出合适类型的信息,可能将来会考虑把它们纳入进来。如下:

var a = {1, 2, 3}; // could infer type int[]
var f = (String s) -> s.length(); // could infer type
                              // Function

尽管存在局限,局部类型推断能帮助缩小Java和其它JVM语言之间的差距,为Java开发人员减少冗余代码。和lambda现在扩充新功能的方式一样,类型推断可能在第一版之后得到提升。这将确认作为新功能实验场所的JVM语言的非官方动态,最流行的新功能最终被引入Java。

本文翻译已获授权,原文链接:

https://www.infoq.com/news/2016/12/java-type-inference-mutability

本文译者:王纯超

机器人的未来:2017~2020年的10个预测

IDC公司全球机器人项目研究总监张敬兵博士,他一直持续不断地关注着机器人的行业趋势,关注着机器人时代当前所面临的机遇和挑战。不久前,张博士结合当前形势,进一步介绍了全球机器人发展的新趋势、推动机器人设备市场需求日益增长的关键因素,以及机器人应用产生的影响、机遇和挑战。在本文中,张博士介绍了他对2017年至2020年的重大战略预测以及机器人技术的主要发展趋势。

IDC是全球著名信息技术、电信行业和消费科技咨询、电子行业观察服务提供商。

机器人技术的未来是什么样的?鉴于该领域以及相关领域如机器学习和人工智能日新月异的发展,这很难预料。但有一点似乎是肯定的:机器人将在商业和生活中发挥越来越重要的作用。

日前,新加坡IDC Manufacturing Insights全球商用机器人研究项目发布了《IDC Future Scape:2017年全球机器人预测》的报告,该报告预计,到2019年,物流、健康、公共事业和资源领域大概有35%的领先机构将会探索使用机器人来实现自动化运营。

该报告公布了2017~2020年全球机器人行业的十大预测。如果他们预测成真,将有可能会对商业和社会产生重大的影响。

张敬兵博士表示:“人工智能、计算机视觉、导航、MEMS传感器和半导体技术的发展,将会推动工业及服务机器人在功能、性能、自主性、易用性和成本效益等方面的创新。”

张敬兵博士透露,机器人技术将会继续加速创新,从而改变许多行业的业务运作模式。IDC鼓励企业“接纳并评估此类机器人技术如何提高企业的竞争优势,如提高质量、提高经营效率和敏捷性,以及改善所有利益相关者的体验。

张敬兵博士在报告中,阐述了机器人技术发展趋势的十大预测,这些趋势将为IT企业带来许多新的机遇和挑战。

  1. 机器人即服务。到2019年,30%的商业服务机器人应用将采取“机器人即服务(RaaS)”业务模式。这将有助于降低部署机器人的成本。

  2. 首席机器人技术官。到2019年,30%的领先机构将实施首席机器人技术官的职位和/或在企业内设置专业的机器人职能部门。

  3. 不断发展的竞争格局。到2020年,用户企业将有更多的供应商选择,因为新的市场参与者进入了ICT市场,带来了800亿美元,支持机器人部署。

  4. 机器人人才危机。机器人技术的增长将加速人才争夺战,导致35%与机器人技术相关工作岗位空缺,与此同时,平均工资增长至少六成以上。

  5. 机器人技术面临监管。到2019年,政府机构将开始实施机器人相关法规以保障就业,应对安全和隐私方面的威胁。

  6. 软件定义的机器人。到2020年,60%的机器人将依靠基于云的软件来定义新的技能、认知能力和应用程序,从而形成机器人技术的“云市场”。

  7. 更多的协作机器人。到2018年,所有新型机器人将有三成是协作机器人,比现在机器人速度要快三倍,而且可以在人类周围安全地工作。

  8. 智能机器人网络。到2020年,将有四成商用机器人连接到共享智能网络,从而将机器人整体操作效率提升200%。

  9. 机器人应用突破工厂范围。到2019年,将有35%的物流、医疗、公共事业和资源领域的领先组织去探索使用机器人实现自动化运营。

  10. 机器人电子商务。到2018年,全球200家领先的全球电子商务和全渠道商务公司中有45%将在其订单履行、仓储和交付业务中部署机器人系统。

其实,我们现在就已经看到机器人技术的曙光了,传统行业如何根据自身特点,结合机器人技术来实现涅槃重生,这就是现下许多行业需要认真思考的问题,事关本企业的生死存亡。

本文作者:刘志勇

今日荐文

点击下方图片即可阅读

不管你承认与否,人工智能的时代即将来临