Java平台发展趋势展望(3)

实验

无论做出什么样的改变，如果它们首先是在开源社区里实现，那么都是令人愉快的，所以我们只要看一下真正的区别有多大或多小。为此，Sun 公司的 Peter Ahè 开始了 java.net 上的 Kitchen Sink Project。目标是要分别地分派和指定 javac 编译器，来测试像这样的许多不同想法。在博客里写写这些可爱的功能是一回事；但真正制造运行的代码则全然是另一回事。

客户机 GUI

尽管许多人还没注意到，但 Java 平台真正出现在桌面上到现在已经有四五年了。已经有几个优质的桌面应用程序是用 Java 代码编写的，包括 RSSOwl、Limewire、Azureus、Eclipse、NetBeans、CyberDuck 等等。这些应用程序几乎用了每一个可用的 GUI 工具包来编写，包括 Swing、AWT、SWT，甚至是平台原生的工具包，如 Mac OS X 的 Cocoa。我看不出下一年会有哪个工具包在众多工具包中胜出，尽管 Swing 在制造一些保留本色的应用程序方面似乎比其他工具包表现得更为出色。

用 Swing 进行开发仍是相对挑战的，但随着 Swing 应用程序框架的到来，这种情况也许会在下一年得到改善。这一框架目前尚在 Java Community Process 中作为 JSR 296 开发。下面是 JSR 关于此的描述：

编写良好的 Swing 应用程序试图为启动和停止，以及管理资源、行为和会话状态的代码使用相同的核心元素。新应用程序从头开始创建所有这些核心元素。Java SE 不支持构造应用程序，这常常让开发新手们感到有点茫然，特别是在他们打算构建一个规模远超于 SE 文档中提供的例子的应用程序时。

通过定义 Swing 应用程序的基本结构，这项规范（最终）会添补该空白。它会定义一小套可扩展的类或 “框架”，用于定义相对于大多数桌面应用程序较普遍的基础设施。
Swing 应用程序框架应支持典型应用程序中的大多数东西，允许开发人员恰在一些自定义的点处插入，如启动和停止时。在启动和停止之间，它将处理 windows 的保存和恢复，以及应用程序的其他部分。最后，它将允许开发人员编写在 Swing 事件分派线程外运行的异步行为。

改善 JavaBeans 以及所有依赖它的东西（包括 Swing）的工作尚在继续。JSR 295 正在定义一种将 bean 绑定到一起的标准方式，这样，对一个 bean 的修改就会自动地反映到其他的 bean。例如，一个 GUI 网格 bean 会在其相关数据库 bean 改变时自动更新。

最终，JSR 303 正在实现一门基于 XML 的验证语言，来声明式地指定任何给定的 bean 将取什么值。int 属性将必须介于 1 到 10 之间，或者 String 属性必须包含一个合法的电子邮件地址。如果幸运，这一切都将在年底以 beta 形式提供，并将在来年的 Java 7 中按时完成。

作为桌面语言的 Java 平台

一些程序员们选择用 Java 代码编写他们的桌面应用程序是因为它们偏爱这门语言，但大多数程序员则是被多平台转换这一强烈的渴望所驱动。对 Java 平台作为桌面语言的兴趣于是就同非 Microsoft 桌面的数目紧紧地联系了起来。让我们认为 Java 编程会在来年出现在三大主流桌面上。

Windows

Swing 在下一年会继续对其类似 Windows 的外观作出小的改进，尤其是转换到开源开发这一部分。结果，纯 Java 程序如 LimeWire 甚至会比在 Windows 下看起来更加具原生感。但开发原生 Windows 应用程序所选择的语言仍是 C#（还有一些 C 和 C++ 的追随者），而开发框架会选用 .NET。Java 代码不会对 Windows 生态系统造成任何显著打击。

Macintosh

像 Microsoft 一样，Apple Inc. 也使用了相当多被抛弃的 Java 代码。Apple 公司喜爱 Objective C 和 Cocoa，但最后的结果是相同的：只用 Mac 的开发人员会继续减少 Java 代码，而选择 Apple 偏爱的语言和环境。

积极的一面是，尽管 Apple 不再在其私有的 API（如 QuickTime 和 Cocoa）中支持 Java 代码，Apple VM 已经比前些年改进了不少。Apple 的 Java 6 移植版不久就会发布。它不会是开源的（不同于 Sun 的 JDK），但开源程序员们还是会着手修补它的 bug。

Linux

GPL 许可协议将使这成为可能，即将 Java 代码绑定到最纯的开源 Linux 发行版中，这将使 Java 平台成为 Linux 开发中更为吸引人的语言。如果这些在五年前发生的话：Linux 社区将不会不得不挣扎于使用 C 语言，而 Mono 也不会成为必要。

已经有了针对 Gnome 和 KDE 的 Java 绑定，所以希望这些会在接下来的一年里吸引更多人的关注。也期望至少有一个即将进行的开发 Linux GUI 程序的主要项目使用 Java 语言而不是 C、C++ 或 C#。

Ruby 取胜

臃肿的软件

JavaScript 已经和 JDK 6 绑定到了一起。其他语言也许会添加进 JDK 7。我觉得那样会有点臃肿。首先，Sun 公司绝不会加入一门语言就停下来。如果它选了 BeanShell，拥护 Groovy 的家伙也会要求加入。如果加入了 Groovy，用 Ruby 的家伙也会坚持要加入。如果 Ruby 加入，还能忽略 Python 吗？标准 JDK 已经太庞大了。支持多种脚本语言是一回事，但将它们绑定到一起还是同一件事吗？策略性的改进应该是支持所有这些语言，但一个也不绑定进来。

积极的一面是，Sun 公司正在研究减小初始下载尺寸和减少应用程序启动时间的方法，尤其是 applet 和 Java Web Start 应用程序。可能的方法是，将大量的类库放到服务器上或放到速度较慢的后台线程中，只下载需要的部分。

如果我们只说一门语言，世界将会索然无味。尽管 Java 平台是开发成熟应用程序的绝佳选择，但它从来就不适应于小程序或宏。Java 6 意识到了这一点，它添加了 javax.script 包实现，以便和脚本语言（如 BeanShell、Python、Perl、Ruby、ECMAScript 和 Groovy）进行互操作，也添加了一项 invokedynamic 虚拟机指令来允许将动态类型语言直接编译为 Java VM。

2007 年，我将宝押在 Ruby 上，尽管它并不是我个人的最爱。对于我来说，Python 代码似乎比 Ruby 代码更简洁更易于理解，我认为大多数 Java 程序员都会这样认为。然而，Python 出来的不是时候。许多开发人员不得不在学习 Python 代码还是学习 Java 代码间作出选择，而多数人选择了 Java 代码。既然他们终于弄懂了 Java 语法，又打算在工具箱中添加另一门语言，他们想要的是明天的语言，而不是昨天的语言，而那门语言似乎就是 Ruby。更重要的是，Ruby 的 Ruby on Rails 是一个绝对杀手级的应用程序。它的简单性对于多数觉悟了的 Java 企业版（Java Enterprise Edition，JEE）开发人员来说具有难以置信的魅力。

除了 Rails，比起其他脚本语言，JRuby 项目和现有的 Java 代码很好或更好地集成到了一起。事实上，JRuby 也许会超越标准 Ruby 分布，并成为 Ruby 程序员们更偏爱的平台，而不止是 Java 程序员们将 Ruby 作为第二种选择。这很好。Python 程序员们会这样反对：他们这些年来已经将 JRuby 最好的方面加入到 Jython 中，他们是对的，但我讨论的是 2007 年将 发生什么，而不是应该 发生什么。这很不幸但却是事实：Ruby 获得了契机，而 Python 没有。

其他脚本语言会被逐渐逐出界外。Perl 太过时了，不能很好地适应现代应用程序。Groovy 缺少明确的视角，还趋向于将计算机科学的时髦用语凌驾于可用性和熟悉性之上，这让它深受其苦。BeanShell、Jelly，还有半打其他语言可能都从未吸引过超过一个的称心追随者。来年的这个时候，到处都会是这样的呐喊：Ruby 将成为 Java 程序员们首选的脚本语言。