JavaOne 2015概览

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客户端，那么所有的一切就都可以免费使用。

https://netbeans.org/downloads

Wielenga：JavaScript的生态系统是非常容易变化得，在新的技术到来的时候，JavaScript也会随之不断地发展。尽管你需要非常仔细地考虑在JavaScript生态系统中，哪一部分是你所需要的，并可以稳定使用，但是你仍然能够在其中开发出有意义的应用。

Paumard：这两个API都是流的一种。简单来说：Java 8 Stream API是关于流，RxJava是关于反应流，这就是他们的区别所在。除此之外，这两种API都允许写入数据处理管道；都可以在同一时间消耗来自不同来源的数据，并连接到自定义源。两者之间最大的不同是在J8环境中，当数据管道从数据来源拉取数据时，RxJava实际上是通过监听产品，来监听那些能独立产生数据的来源。这样就给数据处理管道的设计带来了新的问题。主要问题就是：如果我们的数据处理管道速度不够快，或者不能消耗所有产生的数据，那么会怎么样。这样就引入了背压问题和一些不同的解决方案。我们可以结合Java 8 Streams和Java 8 CompletableFuture，并通过使用JDK 8搭建响应式流。这样就可以提供我们所需的一切了，然而实际搭建起来却非常困难，因此我们必须要有更简单的模式来构造我们的应用。

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可以高效使用，但是在另一些其他的用例中则不行。简而言之，反应模式带来了现代应用中需要的许多东西。但是它仍然在进步，一些常见的问题仍然亟待解决。新的工具正在发展，作为开发者或者应用架构师，我们一定要抱着发展的眼光来看待这些。

Paumard：对于他们宣布近期转向反应式架构的举动，我一点都不感到惊讶。因为Spring团队一直都是新编程框架的引领者，他们过去的成就也向我们展示了他们有创建这种新框架的能力。在微服务中，反应式架构的效果很好，可以为我们提供了一个简洁的设置模型，来帮助融合、链接和组合微服务，并且为我们提供非常好的方法来处理异常。背压一个很难解决的问题，会在每个用例基础中被处理。我非常确信将会在未来看到更多关于这个主题的创新。

Gee：这不是我所能想象得！Java 7的生命已经结束了，相对于Java 8来说，Java 7不具备任何优势。但是，我看到很多的开发者仍然在局限与Java 6之中，因为对于一个技术团队来说，为了不承担风险，他们对新技术的态度仍然比较保守；但是我也看到了许多的团队直接从Java 6完成了到Java 8的转变。

Gee：这是一个普遍的误解，我已经开始后悔使用这个作为我谈话的标题了，在这里并不是“愤怒"的意思，而是表示”在实际生活“中，这是一种英式表达，但是可能即使是英国人也不是都了解这种表达方式！这次谈话的目的是展示Java 8在完全运行的APP中的实际使用，而不是仅仅展示"这是lambda表达式"或者”这是一个流“之类的抽象功能。

至于Java 9当然会加入有不少有趣的新概念，但是我怀疑它对于日常开发的影响和冲击会比Java 8小很多（但话虽如此，Java 9应该会增加不少的Streams API，肯定会解决我现在不喜欢使用流的问题）。

Gee：我想要人们了解到得是开发者在工作中对这些新特性的看法。不仅是学习到了新的语法，而是知道在什么特定的情况下使用lambdas表达式和流，并且改变开发者的思考方式。我也想看看你们是会觉得Java 8的解决方案更好，还是传统的方法更简洁、容易理解。最后，我希望你们的IDE（我当然是指IntelliJ IDEA！）能帮助你们从传统的工作方式转变为使用新的功能。

Pericas-Geertsen：MVC 1.0是一种标准API，因此未来将会变成JavaEE 8的一部分，并被多个供应商支持。因为MVC 1.0是基于已经被许多开发者普遍使用的JAX-RS API。

Pericas-Geertsen：当谈及WEB UI框架的时候，并没有一种万能的解决方案。就像已经有报告称，目前已经有公司在把服务器端框架迁移到客户端后，发生了一些执行错误，因此不得不又迁移回服务器端。这就说明，虽然基于JS的客户端框架虽然非常好用，但是我相信在未来服务器和客户端这两种框架依然会共存。这完全取决于哪种工具更适合开发者使用。

Pericas-Geertsen：我希望开发者能够了解3点：1.MVC 1.0的基本原理；2.MVC 1.0和JAX-RS的关系；3.MVC 1.0的可扩展性。当开发者足够了解MVC 1.0之后，就可以考虑在下一个项目中使用MVC 1.0框架了。

Mann：我不认为这是一个二选一的命题。JavaEE MVC是一个行动导向的框架，就像Spring MVC一样。对有些技术团队来说，他们偏爱传统的行动导向MVC框架；但是，对于另一些技术团队，面向构件的MVC框架也是一个很好的选择。而且，如果由于某些原因你需要同时使用这两种架构模式，也是完全可以的。最初，我们考虑的是在JSF上面构建MVC（这是完全可能的)，但是后来决定把两种模式分离开来。

Mann：我已经在这个行业干了很长时间了，了解软件架构的发展方向经常是摇摆不定的，当然这样也可以让我们更加深入的了解所用框架的利弊。可以肯定地说，永远都不会有一种万能的架构模式，同时适用于所有的案例。当你把所有的框架都放在服务器端时，必定会限制你在浏览器上的操作空间，而且对硬件的需求也会非常大；同理，当你把所有的框架放在客户端，虽然会让你有更大的操作空间，但对客户端的负担也会更大，而且很难同时满足不同浏览器的需求。我认为折中的方案应该是，比起使用纯粹的JS框架，应该尽可能多的增加服务器端架构，当然也不要完全使用服务器端架构。然而无论怎么说，最主要的一点是要让 JavaEE平台尽可能多得支持更多功能。

Mann：MVC开发模式的优势在于它本身就是基于JAX-RS的基础之上搭建的（最初我们是打算把它作为JAX-RS的一部分，但是JAV-RS EG希望把两者分离开来）。因为它实际上是JAX-RS顶端的一层。所以你能轻易地把纯REST服务和具有操作路径和返回视图特点的web app进行混搭（这些在Facelets, JSP或者其他技术中都能得到运用, 例如Velocity和Thymeleaf）。这样就可以允许你把服务器端模板和数据绑定技术运用到其它有意义的地方。

Marsh：Asgard（AWS云管理和应用部署的WEB接口）作为最强大的云部署工具，已经有许多年了。现在，我们在Asgard的基础上研发出了新的部署工具。这个新的部署工具实际上是一个持续交付平台，而不是一个纯粹的部署工具。在管理工作流的时候，这将会是一个功能非常强大的工具。可以让我们在未来的一段时间里拭目以待。

在监控方面，Atlas工具也是非常的不错，但不是所有人都需要这么复杂的工具。我认为其中最核心的是Janitor Monkey，它可以在云服务帮助下清理不用的进程并管理消耗-这就不需要我们自己主动去清理不用的进程了。

Marsh：系统管理员跟那些部署和运行自己编写的服务的开发者相比，所做的工作是完全不同的。例如，系统管理员是需要管理第三方工具。而且开发者运行自己所开发的工具时，很显然会比使用那些他们即不能查看代码，又不能修复Bug的工具要容易的多。

Marsh：DevOps是一个重载术语。就如同之前的敏捷开发一样，我要小心别把它们混淆在一起，我们需要假设它们都是同等重要的。通过从这次谈话中，我最希望开发者可以借助这些工具，帮助他们了解他们的服务到底是如何运行的，并且认识到这些工具可以让他们的企业获益。

Gaur：物联网云服务是一个新增的Oracle PaaS（Platform-as-a-Service）组合。Oracle物联网云服务能够使用户牢固地连接上任何设备，执行及时和预测性的设备数据分析，拓展企业应用中的业务流程。并且为了预防性维护和资源追踪，可以通过Oracle PaaS让物联网应用在高速发展中使用预构一体化。其中，Oracle和第三方SaaS应用包括JD Edwards的Oracle E-Business Suite和Oracle Fusion Applications。

Gaur：物联网是一个拥挤的市场。目前已经有了不少的点方案供应商，但是Oracle在许多方面都是独一无二的，自身有很大的优势：

a）平台：在众多企业之中，Oracle是唯一一个可以提供完整的一体化平台的供应商，其中涵盖了：智慧网关，设备连通性，安全性和企业应用全方位的分析。物联网CS架构能够为许多的企业应用提供即开即用的连通性来进行物联网应用的快速开发。

b）设备虚拟化：首先，它可以让你连接其他公司任何设备。我们把拿出每一个设备都看做一套简单的API。这就意味着像CRM系统和服务云一样企业应用，可以直接跟这些设备交流，而且不用担心类似于传输协议和短信格式之类的技术上细微差别。

c）安全性：安全性毫无疑问是最重要的部分。Oracle物联网云服务会把设备当做是第一级成员（就像APP或用户），并且保障端对端的安全性。

d）分析性：Oracle物联网云服务能够为设备数据提供实时，并且基于历史和大数据的预测性分析。这可以使客户了解设备中数据的流向，识别关键模式和异常，并且驱动决策。

Gaur：在这一块，我们主要是面向企业服务的，就像产业制造、运输和物流一样。当然，我们也会为客户和合作者提供免费的试用来体验物联网云服务。当然了，我们的物联网云服务许多技术组件都是开源的，其中包括物联网云服务的客户端库。

Shmeltzer：我这次的谈话主要是关于Oracle MAF框架（Mobile Application Framework：移动应用框架）。这与你之前所用的TAP框架比起来的话可能会是一次技术革新。MAF是基于MVC框架，并运行在Java开发的设备之上。你可以使用XML来定义的视图，并且可以通过HTML5技术呈现出来，你也可以使用Java来编写你的控件和模型层。

你以此开发的APP应用不管是在Android还是iOS设备上都可以运行。Oracle内部已经使用MAF框架开发了超过100个这样的APP了，并且都已经在iTunes或者Google应用商店里上线。

Shmelter：目前世界上已经有了成千上万的Java工程师，我们现在所做的是让他们可以继续使用已有的技能，来进行移动端的开发。你所使用的语言是你了解得（Java 8），你所使用的IDE也是你熟悉得（Eclipse或者JDeveloper），就连框架也是你所擅长得（MVC，POJOs，基于UI定义的组件）。

对投资Java的IT应用商店来说，我们已经为他们解决了技术上的障碍，让开发者可以利用已有的资源进行移动APP的开发。

Shmeltzer:如果你是一个Java开发工程师，现在已经有了一个解决方案，可以让你利用目前已学的各种技术，无缝转变到新的移动设备开发当中。

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上的注释，来对你进行帮助。

Laforge：我认为不同的人会从这次谈话中会了解到不一样的东西，希望那些经验丰富的Groovy开发者可以学到一些新的Groovy开发技巧，让他们能够在开发时使用；而对于那些刚接触Groovy的开发者来说，我希望他们能看到Groovy的强大功能；而对于那些对Groovy持有怀疑态度的人，我希望这次谈话能够改变他们的看法，认识到Groovy在提高效率，代码可读性，健壮性和领域特定语言（DSL）上能够提供很好的帮助。

我相信对所有的人来说，都可以从这次谈话中学到一些有用的东西。

Bucek：根据浏览器和客户端的支持情况显示——websockets具备一切所需的功能，你可以在任何情况下使用。在必要的时候，有一些框架甚至会效仿websocket连接使用长轮询，但是我认为这些并不重要，因为即便如此开发者也不会去使用这些框架。

不过当涉及到后台基础框架需求的时候，websocket与所谓的“标准”应用可能会存在一些不同，但是如果后台能够支持https协议或者提供一些其它更持久的连接的话，那么这些就不再是问题了。

Bucek：我认为这种说法是无稽之谈。REST框架已经被应用在简单而高效的“RMI远程引用层(Remote Reference Layer)协议”之中，目前为止，我还没有见到任何可以取代它的东西出现。

“响应式API会变成未来发展的主流”——根据目前基础结构的发展来说，我是同意这个观点的。如果你想做异步开发，当然希望接收到得不止一个响应——REST客户端是把所有的响应融合，并且基于所有接收的响应来产生一个响应——这些可以在响应式API的帮助下非常容易地实现，而且不会有任何阻碍和额外的线程，也不必考虑同步问题。

Bucek：

• WebSocket和REST并不是相互竞争的关系，他们是互补的。
• 如果你需要更有效率的双向交流，或者是减少浏览器（或独立应用程序）的反应时间，你应该考虑使用WebSocke协议。
• WebSocket并不会被HTTP/2所取代。