Java 那些事：Java 7、JavaFX 2.0 以及 Vaadin 框架

这一个月以来，在 Java 社区最热门的词应该是 Java 7 了。从 2006 年 12 月 Java SE 6 发布到今年 7 月 28 号 Java SE 7 发布，这其中经过了差不多 5 年的时间。在这过程中发生了太多的事情，甚至连最初开发 Java 的 Sun 公司也被 Oracle 收购了。Oracle 的 Java TCK 的授权协议的问题，最终导致 Apache 基金会退出了 JCP 。而 Java SE 7 对应的 JSR 336 的表决结果也充满了戏剧性：Google 直接投了反对票，而有6 个成员虽然投了赞成票，但是都添加了相关说明，声明自己投赞成票的目的只是基于技术上的考虑和为了推动 Java 的发展。不管怎么说，尽管JCP 中矛盾很多，Java 总算是迎来了它的一个重要的版本。Oracle 也开始着手对JCP 的流程进行更新，以增加流程的透明性。这个被称为 JCP.next 的新的运作方式，虽然没有办法解决核心矛盾所在的授权协议的问题，但是也可以提高 JCP 的工作效率。在另一方面， OpenJDK 的发展一直都不错， SAP 也在上个月加入了 OpenJDK 项目， IBM 和 Apple 则在去年就已经加入了其中。

好事多磨，Java SE 7 在它发布之日（确切地说，是在发布之前5 天），就爆出了HotSpot 虚拟机在循环优化上的重大bug ，可能导致JVM 崩溃或是出现计算错误。对于这种情况，有的网站甚至给出了“在任何情况下都不要使用Java 7 ”这样标题的文章。不过也不用过于担心，Oracle 已经在着手修复这个问题了，最迟在Java SE 7 Update 2 中就可以被修复。Java 7 的发布也在社区里面掀起了不小的讨论，有赞扬的，有批评的。笔者很认同 Bruce Eckel 的观点：Java 7 的发布，总得来说是一件很好的事情。对于像 Java 这样一种使用这么广泛的语言来说，它的发展会造成很大的影响。但是受限于 Java 语言本身设计上的缺陷和向后兼容性的问题，Java 的每一次更新都显得非常困难。这并不是 Java 本身的错误，任何有着较长历史的语言都存在类似的问题。Java 7 中真正对 Java 平台造成重大影响的改进太少，而之前在社区中讨论得很热烈的增加闭包支持的 Project Lambda 和增强模块化的 Project Jigsaw 都被推迟到了 Java 8。可以预期的是，JVM 上的动态语言，如 Scala、JRuby 和 Groovy 等都将得到更加长足的发展。

随着 Java 7 的发布，很多开发工具也做了相应的更新来支持 Java 7。其中的好消息莫过于 Eclipse 3.8M1 版本正式支持了 Java 7 ，而一直对 Java 7 有着很好支持的 NetBeans 也发布了最新的 7.0.1 版本。Eclipse 的动作比较慢一些的原因是因为 Eclipse 采用的是自己的 JDT 中的 Java 编译器，而 Java 7 中的一些新特性是在编译器这个层次来实现的。在应用服务器方面，GlassFish 也发布其支持 Java 7 的 3.1.1 版本。

下面介绍一个出现较早但是最近有重大更新的技术：JavaFX 2.0。

JavaFX 2.0

现在做 Web 应用开发，提得最多的概念就是 RIA，即所谓的富互联网应用程序。在RIA 开发的技术选择中，基本上是两大派别：一个是不依赖插件的开放标准派，依靠Ajax 和最近非常火热的HTML5，其思想是把浏览器作为唯一的运行平台；另外一个派别则是插件派，依靠的是浏览器上的插件来支撑RIA 应用的运行。插件派里面比较重要的参与者是Adobe 的Flex、微软的 Silverlight 和Oracle 的JavaFX。两种派别的做法各有利弊：在HTML5 没有被广泛支持之前，浏览器本身的能力始终有限；而依赖插件的做法无疑会带来部署相关的问题，普通用户可能会被插件的安装过程折磨得放弃使用这个应用了。从部署的角度来说，Adobe 和微软的处境要好得多：Flash 现在基本上是浏览器的标准插件，很少有浏览器不装的，除了iPhone 和iPad 上之外。微软有操作系统平台和浏览器的优势。而Oracle 的JavaFX 则比较尴尬，受限于JRE 的部署状况。

JavaFX 从它 2007 年发布以来，表现一直差强人意。Oracle 收购了 Sun 之后，在 JavaFX 中投入了大量的精力进行推广和更新。JavaFX 最近比较出名的应用应该是在 2010 年温哥华冬奥会上。在调整了JavaFX 中的很多概念，以及重新设计和实现了很多重要组件之后，得到的就是现在的JavaFX 2.0。JavaFX 2.0 的 beta 版已经发布，正式版则定于今年第3 季度发布。在最早的时候，笔者也研究过 JavaFX。不过在当时来说，JavaFX 可用的地方并不多。JavaFX 2.0 的新特性使得开发人员应该需要重新审视它在 RIA 开发领域中的位置。在很多情况下，JavaFX 2.0 也会是不错的选择。

JavaFX 2.0 的一个最重要的改进是放弃了 JavaFX Script。JavaFX Script 本来的目的是为开发人员提供一种简洁的脚本语言，用于创建 RIA 应用。但是，JavaFX Script 并没有达到它的预期目的。其原因在于 JVM 之上已经有很多不错的脚本语言可供使用，JavaFX Script 本身的吸引力不大。开发人员也不愿意学习新的脚本语言。放弃 JavaFX Script 之后，JavaFX 的功能全部通过 Java 语言来访问。这是一种很明智的做法，可以利用广大的 Java 开发者群体和社区优势，也有利于复用已有的资产。

JavaFX 2.0 实现了自己的一套图形用户界面库，不同于 Java 平台上已有的 AWT 和 Swing。从适用性上来说，AWT 和 Swing 比较适合传统的以内容为主的交互性较弱的桌面应用。这点从 AWT 和 Swing 中包含的组件就可以看得出来，只是一些常见的内容驱动组件，甚至没有图表的支持，只能依靠 JFreeChart 这样的第三方库。如果需要创建内容丰富的界面，则需要利用 Java 2D 和 Java 3D API 来自行绘制。对多媒体的支持也不够有限。JavaFX 2.0 新的图形用户界面库把基本图形元素和用户界面组件两类元素统一在一起。不管是矩形、椭圆、按钮还是表格，都是用户界面上的节点，可以用相似的方式来处理。JavaFX 2.0 在 JVM 之上，实现了新的类似 AWT 的窗口工具箱 Glass Windowing Toolkit，可以直接利用操作系统的原生事件队列。从此再也不需要小心注意 AWT 和 Swing 中事件分发线程的使用问题了。 JavaFX 2.0 中的图形渲染引擎Prism 可以借助底层操作系统上的DirectX 和OpenGL 提供的硬件加速支持，因此性能优于传统的使用Java 2D 进行软件渲染的做法。在用户界面组件方面，除了基本的常用组件之外，还提供了图表绘制的支持。在多媒体支持方面，除了基本的图片之外，JavaFX 2.0 的媒体引擎支持MP3、AIFF 和WAV 等音频格式和FLV 视频格式。

在组件的外观方面，JavaFX 2.0 也采用了更加流行的做法，即用CSS 来定义应用的外观。另外，JavaFX 2.0 也引入了界面描述语言 FXML 。FXML 在功能上类似微软的 XAML ，是一种用户界面描述语言。FXML+CSS+Java 这样的组合，颇有些 Web 应用开发中 HTML+CSS+JavaScript 组合的味道。

值得重点介绍的是 JavaFX 2.0 中的 Web 引擎组件。这是一个基于 Webkit 内核的内嵌浏览器。在 JavaFX 应用中可以访问内嵌浏览器中网页的 DOM 结构和执行 JavaScript 代码。基于 Webkit 意味着这个内嵌浏览器支持 HTML5 的新特性。这个内嵌浏览器可以在很多场景下都得到应用，比如 Web 应用的自动化测试。另外一种用法是把内嵌浏览器作为 Web 应用运行时刻的环境，以一种 Java+HTML 的方式来呈现。

JavaFX 2.0 至少把 Java 平台变成了一个开发富客户端应用（RCP）的良好平台。在以后的开发中，AWT 和 Swing 应该会逐渐淡出桌面应用开发的视野。 JavaFX 将成为 Java 平台上主流的图形用户界面开发库。而在 RIA 方面，JavaFX 的前景仍无法预料。毕竟，依赖插件的 RIA 开发方式都受到来自 HTML5 的巨大冲击，JavaFX 自然也不例外。JavaFX 能发挥作用的一个地方应该是在企业内部系统中。对于企业内部的系统，部署上的问题比较好解决，同时也有利于复用内部的 Java 相关的资产。

Vaadin 框架

对于 Vaadin 这个框架，很早之前就有听说过，但是并没有去具体关注它，毕竟现在的 RIA 开发框架实在太多了。不过在 O’Reilly 举办的 OSCON 2011 大会上见到了有 Vaadin 的主题，就仔细的关注了一下这个框架。Vaadin 是一个服务器端实现的 RIA 框架，这与一般的客户端实现的 RIA 有很大的不同。一般的客户端 RIA 实现中，服务器端基本上只负责处理数据，并暴露 REST 风格的接口；而客户端则依托 JavaScript 框架或浏览器插件来实现复杂的界面逻辑。服务器端 RIA 的好处在于客户端的逻辑变简单了，但是交互性却没有受到影响。这是依靠 Vaadin 的界面组件来实现的。Vaadin 中的界面组件包括服务器端的 Java 实现和该组件在客户端的对等体（peer）。组件对等体之间的通信由框架完全负责。Vaadin 的客户端组件是通过 Google 的 GWT 转换出来的，但是 Vaadin 相对于 GWT 来说的一个重要优势在于 Vaadin 只包含服务器端的 Java 实现，可以完全忽略客户端的存在。客户端的处理完全由框架来完成。

Vaadin 框架非常适合产品的快速原型开发。因为它只有服务器端的 Java 实现，在原型开发中要考虑的因素很少，可以快速完成。而在实际的项目中，如果是传统的数据库驱动的信息管理系统，Vaadin 也比较合适。如果对 Vaadin 感兴趣，可以查看它的演示站点和与其他 RIA 框架的比较。