作为甲骨文公司的重要大会,2015 年 JavaOne 会议将于本周在 San Franciso 举办,InfoQ 采访了那些在会议上吸引人们关注的发言人。
企业应用中的HTML5和JavaScript客户端
Oracle,高级产品经理,John Brock
Oracle,高级产品经理,Geertjan Wielenga
InfoQ:如何把 NetBeans 纳入发展中的企业 HTML5 和 JavaScript 客户端中的呢?
Wielenga:NetBeans 的主要功能是可以将世界各地的开发者连接在一起,共同解决技术难题。例如,NetBeans 可以在使用 AngularJS 和其他 JavaScript 框架的时候,为开发者提供即开即用的工具;也可以在使用 JavaScript、CSS 和 HTML 的时候,为开发者提供高级编辑器。而且在 NetBeans 中也有专门为谷歌 Chrome 浏览器研发的插件,让谷歌 Chrome 浏览器可以和 NetBeans 进行交互。例如,当 NetBeans 发生变化的时候,也会立刻在谷歌 Chrome 中进行更新;当你点击谷歌中的 app 应用时,不管是在 PC 端,还是在移动端,你都可以看到被 NetBeans 定义的相关 DOM(Document Object Model:文档对象模型)元素在哪。不仅如此,NetBeans 还集成了 Cordova 的许多功能,可以在以下链接中具体了解:
https://netbeans.org/features/html5/index.html
如果你在一个快速响应的工具中下载了绑定 NetBeans IDE(Integrated Development Environment:集成开发环境)HTML5/JavaScript 客户端,那么所有的一切就都可以免费使用。
InfoQ:请问你希望别人能从这次谈话中了解些什么呢?
Wielenga:JavaScript 的生态系统是非常容易变化得,在新的技术到来的时候,JavaScript 也会随之不断地发展。尽管你需要非常仔细地考虑在 JavaScript 生态系统中,哪一部分是你所需要的,并可以稳定使用,但是你仍然能够在其中开发出有意义的应用。
Java 8 Stream API和RxJava**** 的对比:模式和表现
JPEFI 公司,CTO,José Paumard
InfoQ:这边你认为 Java 8 Stream API 和 RxJava 之间的主要差异是在哪呢?
Paumard:这两个 API 都是流的一种。简单来说:Java 8 Stream API 是关于流,RxJava 是关于反应流,这就是他们的区别所在。除此之外,这两种 API 都允许写入数据处理管道;都可以在同一时间消耗来自不同来源的数据,并连接到自定义源。两者之间最大的不同是在 J8 环境中,当数据管道从数据来源拉取数据时,RxJava 实际上是通过监听产品,来监听那些能独立产生数据的来源。这样就给数据处理管道的设计带来了新的问题。主要问题就是:如果我们的数据处理管道速度不够快,或者不能消耗所有产生的数据,那么会怎么样。这样就引入了背压问题和一些不同的解决方案。我们可以结合 Java 8 Streams 和 Java 8 CompletableFuture,并通过使用 JDK 8 搭建响应式流。这样就可以提供我们所需的一切了,然而实际搭建起来却非常困难,因此我们必须要有更简单的模式来构造我们的应用。
InfoQ:你认为 RxJava 会是未来技术的发展趋势吗?
Paumard:目前围绕反应式流已经提出了不少的想法,RxJava 就是其中的一种,当然解决方案肯定不止这一种。目前我们尝试在 JDK 中创建 Reactive Stream API,不过可能要到 Java 9 中才能实现。我将会在另一次谈话“Java 反应式编程”中描述这些 API。Java 9 将会提供一个接口的通用设置,并且让其中的一些类实现了响应式 API 的互用性 ( http://gee.cs.oswego.edu/dl/jsr166/dist/docs/ 然后寻找 Flow 类)。正如我一直所说得,我不推荐在 Java 中使用 RxJava,因为这些基于 10k 行代码和 250 种方法类的 API 过于复杂。因此显而易见,我们离所谓的“整洁代码”还有不小的距离,而且静态方法的大量使用也使得测试工作完全是一场噩梦。实际上,RxJava 是.NET API 的一种复制。作为复制版本,其中当然会有不少的缺点。其中之一就是,在一些用例中 RxJava 可以高效使用,但是在另一些其他的用例中则不行。简而言之,反应模式带来了现代应用中需要的许多东西。但是它仍然在进步,一些常见的问题仍然亟待解决。新的工具正在发展,作为开发者或者应用架构师,我们一定要抱着发展的眼光来看待这些。
InfoQ:你这边是如何看待 Spring 团队近期宣布得,Spring 5 框架将会聚焦于响应式架构这件事呢?
Paumard:对于他们宣布近期转向反应式架构的举动,我一点都不感到惊讶。因为 Spring 团队一直都是新编程框架的引领者,他们过去的成就也向我们展示了他们有创建这种新框架的能力。在微服务中,反应式架构的效果很好,可以为我们提供了一个简洁的设置模型,来帮助融合、链接和组合微服务,并且为我们提供非常好的方法来处理异常。背压一个很难解决的问题,会在每个用例基础中被处理。我非常确信将会在未来看到更多关于这个主题的创新。
Java 8的“愤怒"
JetBrains,开发代言人,Trisha Gee
InfoQ:对开发者来说,有什么原因会使他们仍然使用 Java 7 呢?
Gee:这不是我所能想象得!Java 7 的生命已经结束了,相对于 Java 8 来说,Java 7 不具备任何优势。但是,我看到很多的开发者仍然在局限与 Java 6 之中,因为对于一个技术团队来说,为了不承担风险,他们对新技术的态度仍然比较保守;但是我也看到了许多的团队直接从 Java 6 完成了到 Java 8 的转变。
InfoQ:从你谈话的主题来看,我猜你对 Java 8 的使用不是很多,并且不是很认同其中的一些功能,可以谈谈主要是那些功能吗?Java 9 是否可以改进这些功能?
Gee:这是一个普遍的误解,我已经开始后悔使用这个作为我谈话的标题了,在这里并不是“愤怒"的意思,而是表示”在实际生活“中,这是一种英式表达,但是可能即使是英国人也不是都了解这种表达方式!这次谈话的目的是展示 Java 8 在完全运行的 APP 中的实际使用,而不是仅仅展示"这是 lambda 表达式"或者”这是一个流“之类的抽象功能。
至于 Java 9 当然会加入有不少有趣的新概念,但是我怀疑它对于日常开发的影响和冲击会比 Java 8 小很多(但话虽如此,Java 9 应该会增加不少的 Streams API,肯定会解决我现在不喜欢使用流的问题)。
InfoQ:你希望别人能从这次谈话中了解到一些什么东西呢?
Gee:我想要人们了解到得是开发者在工作中对这些新特性的看法。不仅是学习到了新的语法,而是知道在什么特定的情况下使用 lambdas 表达式和流,并且改变开发者的思考方式。我也想看看你们是会觉得 Java 8 的解决方案更好,还是传统的方法更简洁、容易理解。最后,我希望你们的 IDE(我当然是指 IntelliJ IDEA!)能帮助你们从传统的工作方式转变为使用新的功能。
MVC 1.0介绍(JSR 371:JavaEE 8的新MVC**** 框架)
Oracle,资深技术咨询顾问,Santiago Pericas-Geertsen
InfoQ:为什么开发者要使用 MVC 1.0 框架而不使用更流行的 Spring MVC 框架呢?
Pericas-Geertsen:MVC 1.0 是一种标准 API,因此未来将会变成 JavaEE 8 的一部分,并被多个供应商支持。因为 MVC 1.0 是基于已经被许多开发者普遍使用的 JAX-RS API。
InfoQ:JavaScript MVC 框架似乎比传统的服务器端框架更受欢迎。在客户端 MVC 框架更流行的今天,为何我们需要服务器端的 MVC 框架呢?
Pericas-Geertsen:当谈及 WEB UI 框架的时候,并没有一种万能的解决方案。就像已经有报告称,目前已经有公司在把服务器端框架迁移到客户端后,发生了一些执行错误,因此不得不又迁移回服务器端。这就说明,虽然基于 JS 的客户端框架虽然非常好用,但是我相信在未来服务器和客户端这两种框架依然会共存。这完全取决于哪种工具更适合开发者使用。
InfoQ:你希望别人能从这次谈话中了解到一些什么呢?
Pericas-Geertsen:我希望开发者能够了解 3 点:1.MVC 1.0 的基本原理;2.MVC 1.0 和 JAX-RS 的关系;3.MVC 1.0 的可扩展性。当开发者足够了解 MVC 1.0 之后,就可以考虑在下一个项目中使用 MVC 1.0 框架了。
WEB应用与HTML5网页组件、Polymer和JavaEE MVC 1.0**** 框架的关系
Virtua, Inc,首席顾问,Kito Mann
InfoQ:你正在谈论 JavaEE MVC,但你又一直是 JSF 的提倡者。那么你认为 MVC 1.0 与 JSF 那个更好呢?
Mann:我不认为这是一个二选一的命题。JavaEE MVC 是一个行动导向的框架,就像 Spring MVC 一样。对有些技术团队来说,他们偏爱传统的行动导向 MVC 框架;但是,对于另一些技术团队,面向构件的 MVC 框架也是一个很好的选择。而且,如果由于某些原因你需要同时使用这两种架构模式,也是完全可以的。最初,我们考虑的是在 JSF 上面构建 MVC(这是完全可能的),但是后来决定把两种模式分离开来。
InfoQ:JavaScript MVC 框架似乎比传统的服务器端框架更受欢迎。在客户端 MVC 框架更流行的今天,为何我们还需要服务器端的 MVC 框架呢?
Mann:我已经在这个行业干了很长时间了,了解软件架构的发展方向经常是摇摆不定的,当然这样也可以让我们更加深入的了解所用框架的利弊。可以肯定地说,永远都不会有一种万能的架构模式,同时适用于所有的案例。当你把所有的框架都放在服务器端时,必定会限制你在浏览器上的操作空间,而且对硬件的需求也会非常大;同理,当你把所有的框架放在客户端,虽然会让你有更大的操作空间,但对客户端的负担也会更大,而且很难同时满足不同浏览器的需求。我认为折中的方案应该是,比起使用纯粹的 JS 框架,应该尽可能多的增加服务器端架构,当然也不要完全使用服务器端架构。然而无论怎么说,最主要的一点是要让 JavaEE 平台尽可能多得支持更多功能。
InfoQ:如果我作为开发者,想利用 web 组件和 Polymer 工具开发一个 webapp,为什么我要在服务器端用 MVC 1.0 架构而不是 JAX-RX 呢?
Mann:MVC 开发模式的优势在于它本身就是基于 JAX-RS 的基础之上搭建的(最初我们是打算把它作为 JAX-RS 的一部分,但是 JAV-RS EG 希望把两者分离开来)。因为它实际上是 JAX-RS 顶端的一层。所以你能轻易地把纯 REST 服务和具有操作路径和返回视图特点的 web app 进行混搭(这些在 Facelets, JSP 或者其他技术中都能得到运用, 例如 Velocity 和 Thymeleaf)。这样就可以允许你把服务器端模板和数据绑定技术运用到其它有意义的地方。
**Netflix如何看待DevOps-“捣乱者”?:**并不是
Netflix,工程总监,Dianne Marsh
InfoQ:众所周知,Netfix 是云计算的最先使用者,并且开发了许多的开源云工具。这边作为 Netflix 公司的工程总监,你会推荐使用什么样的开源工具来使得云端部署和监控变得更容易呢?
Marsh: Asgard(AWS 云管理和应用部署的 WEB 接口)作为最强大的云部署工具,已经有许多年了。现在,我们在 Asgard 的基础上研发出了新的部署工具。这个新的部署工具实际上是一个持续交付平台,而不是一个纯粹的部署工具。在管理工作流的时候,这将会是一个功能非常强大的工具。可以让我们在未来的一段时间里拭目以待。
在监控方面,Atlas 工具也是非常的不错,但不是所有人都需要这么复杂的工具。我认为其中最核心的是 Janitor Monkey,它可以在云服务帮助下清理不用的进程并管理消耗 - 这就不需要我们自己主动去清理不用的进程了。
InfoQ:当越来越多的开发者开始扮演操作者的角色的时候,系统管理员未来的出路在哪呢?
Marsh:系统管理员跟那些部署和运行自己编写的服务的开发者相比,所做的工作是完全不同的。例如,系统管理员是需要管理第三方工具。而且开发者运行自己所开发的工具时,很显然会比使用那些他们即不能查看代码,又不能修复 Bug 的工具要容易的多。
InfoQ:你这边主要希望人们从这次谈话中了解些什么呢?
Marsh:DevOps 是一个重载术语。就如同之前的敏捷开发一样,我要小心别把它们混淆在一起,我们需要假设它们都是同等重要的。通过从这次谈话中,我最希望开发者可以借助这些工具,帮助他们了解他们的服务到底是如何运行的,并且认识到这些工具可以让他们的企业获益。
Oracle**** 物联网云服务概述
Oracle,高级产品总监,Harish Gaur
Oracle,物联网云服务,首席产品经理,Pete St pierre
InfoQ:Oracle 的物联网云服务是什么?
Gaur:物联网云服务是一个新增的 Oracle PaaS(Platform-as-a-Service)组合。Oracle 物联网云服务能够使用户牢固地连接上任何设备,执行及时和预测性的设备数据分析,拓展企业应用中的业务流程。并且为了预防性维护和资源追踪,可以通过 Oracle PaaS 让物联网应用在高速发展中使用预构一体化。其中,Oracle 和第三方 SaaS 应用包括 JD Edwards 的 Oracle E-Business Suite 和 Oracle Fusion Applications。
InfoQ:那么在这个领域内谁是会是你的竞争对手,而且你会怎样做来使你的产品变得更好呢?
Gaur:物联网是一个拥挤的市场。目前已经有了不少的点方案供应商,但是 Oracle 在许多方面都是独一无二的,自身有很大的优势:
a)平台:在众多企业之中,Oracle 是唯一一个可以提供完整的一体化平台的供应商,其中涵盖了:智慧网关,设备连通性,安全性和企业应用全方位的分析。物联网 CS 架构能够为许多的企业应用提供即开即用的连通性来进行物联网应用的快速开发。
b)设备虚拟化:首先,它可以让你连接其他公司任何设备。我们把拿出每一个设备都看做一套简单的 API。这就意味着像 CRM 系统和服务云一样企业应用,可以直接跟这些设备交流,而且不用担心类似于传输协议和短信格式之类的技术上细微差别。
c)安全性:安全性毫无疑问是最重要的部分。Oracle 物联网云服务会把设备当做是第一级成员(就像 APP 或用户),并且保障端对端的安全性。
d)分析性:Oracle 物联网云服务能够为设备数据提供实时,并且基于历史和大数据的预测性分析。这可以使客户了解设备中数据的流向,识别关键模式和异常,并且驱动决策。
InfoQ:你这个提议的主要是目标是针对企业,还是希望针对开发者呢?你会为学生群体提供免费的使用并开放源代码吗?
Gaur:在这一块,我们主要是面向企业服务的,就像产业制造、运输和物流一样。当然,我们也会为客户和合作者提供免费的试用来体验物联网云服务。当然了,我们的物联网云服务许多技术组件都是开源的,其中包括物联网云服务的客户端库。
使用Java 8构建 ****iOS APP
Oracle,产品主管,Shay Shmeltzer
InfoQ:几年以前,我曾在 Oracle 工作过一段时间,当时我们是使用得是类似于 JSF 的“TAP”框架来进行 iPad 开发,这样可以让开发者通过使用 XML 语言来发布 iOS 应用软件。你这次的谈话中有提到关于这个框架的内容吗,或者你们现在已经有了其它更新或者更好的开发框架呢?
Shmeltzer:我这次的谈话主要是关于 Oracle MAF 框架(Mobile Application Framework:移动应用框架)。这与你之前所用的 TAP 框架比起来的话可能会是一次技术革新。MAF 是基于 MVC 框架,并运行在 Java 开发的设备之上。你可以使用 XML 来定义的视图,并且可以通过 HTML5 技术呈现出来,你也可以使用 Java 来编写你的控件和模型层。
你以此开发的 APP 应用不管是在 Android 还是 iOS 设备上都可以运行。Oracle 内部已经使用 MAF 框架开发了超过 100 个这样的 APP 了,并且都已经在 iTunes 或者 Google 应用商店里上线。
InfoQ:为什么你认为开发者会使用 Java 语言来开发他们的 iOS APP 呢?
Shmelter:目前世界上已经有了成千上万的 Java 工程师,我们现在所做的是让他们可以继续使用已有的技能,来进行移动端的开发。你所使用的语言是你了解得(Java 8),你所使用的 IDE 也是你熟悉得(Eclipse 或者 JDeveloper),就连框架也是你所擅长得(MVC,POJOs,基于 UI 定义的组件)。
对投资 Java 的 IT 应用商店来说,我们已经为他们解决了技术上的障碍,让开发者可以利用已有的资源进行移动 APP 的开发。
InfoQ: 你这边希望人们从这次谈话中了解些什么呢?
Shmeltzer: 如果你是一个 Java 开发工程师,现在已经有了一个解决方案,可以让你利用目前已学的各种技术,无缝转变到新的移动设备开发当中。
Groovy**** 风格
Restlet,产品忍者和 Restlet 提倡者,Guillaume Laforge
InfoQ:我留意到你最近发表了一篇文章,内容是自从迁移到 Apache 服务器上之后,Groovy 的下载量有了成倍地增长。你认为其中最主要的原因是 Android 嘛?
Laforge:坦率地说确实有一定的关系,因为我们可以清楚地看到类似于 New York Times 这样的 Android app,已经在 Apache Groovy 上被成功重写了,我的博客中也进行了解释:
http://open.blogs.nytimes.com/2014/08/18/getting-groovy-with-reactive-android/
间接来说,因为 Android 工程师开发 APP 所用的自动化工具,是 Google 选择用 Gradle 来构建得。而 Gradle 上用来做 DSL 开发得则是 Groovy,因此自然越来越多的开发者都开始了解 Groovy。
但是更重要的原因是,许多的公司和项目都开始转向使用 Gradle。因此除了 Android 之外,我们把 Gradle 看做是促使 Groovy 普遍使用的关键因素。
最后但是很重要的一点,我也认为把 Groovy 迁移到 Apache Software Foundation 上本身就有很大的吸引力,因为开发者们知道 Apache Groovy 经过了长期运行,技术上已经十分成熟,因此会被广大的开发者们所信任。
InfoQ:你能分享你认为最重要的三点,可以更有效率地使用 Groovy 吗?
Laforge:如果只能挑选 3 点的话,这就比较难了!
1)第一,你可以使用 Java 开发的方法,因为 Groovy 是 Java 的一种超集。但是当你学习 Groovy 的时候,你要逐步的学习新的技巧来使你的代码更简洁,表达更清晰,也更健壮。
2)第二,学会使用 GDK(Groovy Development Kit:Groovy 开发工具)。Apache Groovy 会提供海量的 API 和方法来修饰 JDK class 文件,这些都是很有用的,能够提高开发效率。
3)最后但是很重要的一点,是类型协议的概念。你可以在任何地方使用“def 方法”,把变量、参数、领域等定义为动态类型,但这并不是一个很好的做法。你需要给所用的 API 一个清晰的协议。因此当申明变量、参数、领域时, 你需要使用合适的类型。这样可以帮助你增强与 Java 的互用性(当你在同一个项目中混合使用这两者语言时),可以帮助你进行记录(考虑到 JavaDoc/GroovyDoc),你的编译器在这种编写方式的协助下也会更容易使用(导航,代码补全,潜在问题等)
你也可以使用 @CompileStatic 或者 @TypeChecked 上的注释,来对你进行帮助。
InfoQ:你这边希望别人从这次会谈中了解些什么呢?
Laforge:我认为不同的人会从这次谈话中会了解到不一样的东西,希望那些经验丰富的 Groovy 开发者可以学到一些新的 Groovy 开发技巧,让他们能够在开发时使用;而对于那些刚接触 Groovy 的开发者来说,我希望他们能看到 Groovy 的强大功能;而对于那些对 Groovy 持有怀疑态度的人,我希望这次谈话能够改变他们的看法,认识到 Groovy 在提高效率,代码可读性,健壮性和领域特定语言(DSL)上能够提供很好的帮助。
我相信对所有的人来说,都可以从这次谈话中学到一些有用的东西。
REST和基于WebSocket**** 的微服务架构模式将如何发展
Oracle,首席软件工程师,Pavel Bucek
Sapho,软件工程师,Michal Gajdos
InfoQ:根据 caniuse.com 上所说的,websockets 协议可以被所有的主流浏览器支持。那么还没有什么其他的原因会造成开发者不使用 websockets 呢?
Bucek:根据浏览器和客户端的支持情况显示——websockets 具备一切所需的功能,你可以在任何情况下使用。在必要的时候,有一些框架甚至会效仿 websocket 连接使用长轮询,但是我认为这些并不重要,因为即便如此开发者也不会去使用这些框架。
不过当涉及到后台基础框架需求的时候,websocket 与所谓的“标准”应用可能会存在一些不同,但是如果后台能够支持 https 协议或者提供一些其它更持久的连接的话,那么这些就不再是问题了。
InfoQ:我最近有听说“REST”架构即将被淘汰,响应式 API 将会变成以后的主流,你认同这个说法吗?
Bucek:我认为这种说法是无稽之谈。REST 框架已经被应用在简单而高效的“RMI 远程引用层 (Remote Reference Layer) 协议”之中,目前为止,我还没有见到任何可以取代它的东西出现。
“响应式 API 会变成未来发展的主流”——根据目前基础结构的发展来说,我是同意这个观点的。如果你想做异步开发,当然希望接收到得不止一个响应——REST 客户端是把所有的响应融合,并且基于所有接收的响应来产生一个响应——这些可以在响应式 API 的帮助下非常容易地实现,而且不会有任何阻碍和额外的线程,也不必考虑同步问题。
InfoQ:你这边希望别人从这次会谈中了解些什么呢?
Bucek:
- WebSocket 和 REST 并不是相互竞争的关系,他们是互补的。
- 如果你需要更有效率的双向交流,或者是减少浏览器(或独立应用程序)的反应时间,你应该考虑使用 WebSocke 协议。
- WebSocket 并不会被 HTTP/2 所取代。
InfoQ 非常感谢这些接受访问的发言者。当然,除了上面提及的一些谈话,2015 年 JavaOne 大会中还有许多其它的部分。与会者将有机会了解到目前一些最前沿的技术,比如:Java 语言最新的变化,现代的企业应用,丰富的客户端解决方案,定位智能硬件的物联网发展和 WEB 服务在云上的发展。
这次会议的主旨是促进 Java 在世界上地发展,会议时间为 10 月 25 日星期天下午 1:45-4PDT(Pacific Daylight Time:太平洋夏季时间)。同时你可以在 http://www.oracle.com/javaone/live 网站上观看直播。
查看英文原文: JavaOne 2015 Preview
感谢张龙对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群(已满),InfoQ 读者交流群(#2))。
评论