这一个月以来，在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框架的比较。