2007 年将是载入史册的一年，Sun Microsystems 公司将于这一年在开源许可协议下发布 Java 开发包(JDK)，从而放弃了对 Java™ 平台的统驭，将权力交给了 Java 开发人员社区!在本文中，Java 开发人员 Elliotte Rusty Harold 从各个方面预测了 Java 平台的新方向，从脚本到 bug 修复到新语法。

　　2006 年又是 Java 平台繁荣的一年。尽管遭遇了来自 Microsoft(C#)和脚本语言社区(Ruby)的冲击，但 Java 语言仍然保持着其世界头号编程语言的地位。同时，尽管 Java 6 的发布很值得庆祝，但比起宣布 Java 将在 GNU General Public License 下完全开源这一事件来说，却不免有些黯然失色。Java 在 2007 年还能保持这种势头吗?让我们来看一下成败的可能。

　　Java 平台将成为开源平台

　　2007 年上半年，Sun 将在一个开源许可协议下发布 Java 开发包(JDK)。解除 JDK 的禁锢对于 Java 开发人员社区来说是巨大的一步，它将在今后的十年中推动 Java 平台的发展。

　　JDK 的质量将会显著改善，因为程序员们不再仅仅报告 bug 并开始修复。Java Developer Connection 的 bug 报告将会包括对 JDK 中的问题部分的详细分析，并提供修复的补丁。正如Linus 法则 所陈述的那样，“只要给予足够的关注，任何 bug 都是显而易见”，即调试是可并行进行的。优化也是一样。开源使两者得以 并行。

　　分支项目

　　遗憾的是，设计并不是和调试、优化一样可以并行完成的。清洁的 API 有时也需要有一只独裁的手。但独裁者的缺点是：有时他们知道在做什么，有时却不知道。意图成为独裁者的各方面之间的竞争往往是发现问题最佳解决方案的惟一方式。

　　很少有公司能够负担得起这样的代价，为一个产品开发多个独立的实现，以便在多个产品中选定保留一个而摒弃其余的产品，但开源社区却在朝这个方向 努力。所以，您会在 Java 平台的各个层次中发现分支产品：语言、虚拟机和库。大多数的分支产品会失败，但这没什么。好主意会脱颖而出。一些分支产品会一直存在下去，一些会重新并入 标准 JDK 中。明年的这个时候，分支产品与主流产品之间的差异也许不会很明显，但这个过程会继续下去。

　　Sun 会在几个月后发布 Java 7，Dolphin 的一个早期的 beta 版，以此作为开端。Sun 无法发布更早的 JDK 版本，因为存在一些只有在 Dolphin 中才能解决的构建问题和许可协议问题。尽管如此，仍有望看到第三方着手进一步细分 Sun 的版本，来提供 Java 6、Java 5、Java 1.4，甚至更早版本的流行开源实现。

　　早期的一些探寻分支产品的人们可能会侵犯 Sun 公司的商标，收到 Sun 的律师寄来的讨厌的律师信。我们需要一个通用的未注册为商标的名字，让所有人都能使用。我建议用 “J” —— 我希望没人用单字母作商标。

　　开源项目从未消亡，只是有些褪色。就像之前的 Blackdown Project、GNU Classpath、Kaffe 和其他开源 JDK 项目一样，他们的开发人员都转向其他事情了。如果一个项目至今还没有达到 1.0，那么恐怕以后永远也达不到了。

　　期待 Java 7

　　Dolphin 不会在 2007 年发布。2008 年是更为现实的目标。那就是说，工作尚在进行中，它的一些功能也许会作为早期的标准扩展或至少作为 beta 登场。

　　遗憾的是，为一门语言添加功能远比删除功能要简单得多。几乎不可避免地，随着时间的推移，语言不是朝着简单的方向发展，而是越来越复杂，越来越让人困惑。即使是那些单独看起来很好的功能，在彼此叠加后也会出现问题。

　　令人遗憾，Java 社区没有接受这个教训，尽管这种失败并无特殊性。但总有一些太酷又太让人激动的新语法令语言设计者难以抗拒 —— 即便这样的新语法不能解决任何实际问题。于是对 Java 7 的新语言功能就有了巨大的要求，包括闭包、多继承和操作符重载。

　　我猜想在这一年结束前，会在 Java 7 beta 中看到闭包，也许还能看到操作符重载(有五成的把握)，但不会出现多继承。Java 中有太多东西是基于单个根的继承层次。没有可行的方式改进多继承，使之适应这门语言。

　　目前有许多语法糖方面的提议，有一些有意义，有一些没有。许多提议都专注于将像 getFoo() 这样的方法替换为像 -> 这样的操作符。

列表

最有可能的是使用数组语法来实现集合访问。例如，不再采用下面这样的代码：

List content = new LinkedList(10);
content.add(0, "Fred");
content.add(1, "Barney");
String name = content.get(0);

而是编写如下代码：

List content = new LinkedList(10);
content[0] = "Fred";
content[1] = "Barney";
String name = content[0];

另一种可能性是：允许为列表使用数组初始化程序语法。例如：

LinkedList content = {"Fred", "Barney", "Wilma", "Betty"}

这两项提议都可以在不改变虚拟机（VM）的前提下由编译器稍显神通即可实现，这是任何修订过的语法的一项重要特征。这两项提议都不能使任何现有的源代码失效或重定义现有的源代码，对于新语法来说，这是一个更为重要的问题。

真 正能够影响开发人员生产力的特性功能应该是用于管理表、树和映射表的内置原语，比如在使用 XML 和 SQL 时遇到的那些。JavaScript 下的 E4X 项目和 Microsoft 的 Cω 和 Linq 项目是实现这一想法的先驱，但可悲的是，Java 平台似乎错过了这个机会。如果有人想要通过编译器来玩一个潜在的救场的游戏，这里是一个不容错过的好地方。

属性

很可以还有一些针对属性访问的语法糖。一个建议是使用 -> 作为调用 getFoo 和 setFoo 的缩写。例如，不再使用如下代码：

Point p = new Point();
p.setX(56);
p.setY(87);
int z = p.getX();

而是使用如下代码：

Point p = new Point();
p->X = 56;
p->Y = 87;
int z = p->X;

也有人建议用另外一些符号来代替 ->，包括 . 和 #。

将来，您有可能必须将 Point 类中的相关字段显式地标识为属性，如：

public class Point {

  public int property x;
  public int property y;

}

我个人对此并未产生什么深刻的印象。我宁愿 Java 平台采纳一项更为激进的方法，让我们可以真正地使用公共字段。然而，如果将 getter 或 setter 定义为与字段相同的名称，然后读写字段就会自动地分派到相应方法中。这样做所使用的语法更少，也更加灵活。

随机精度算法

非操作符重载 值得一提的是，对标准数学符号的重用不同于 操作符重载，至少不是在 C++ 中引起问题的那种重载。加号和其他操作符在任何程序中都具有明确的意义。无论在哪一个程序中，它们的意义都不会有所更改。对于相似的操作重用相同的语法让 代码更易于阅读。若重新定义语法，使之在不同的程序中有不同的意义，代码就会较难理解。

另一项将方法替换为操作符的建议致力于 BigDecimal 和 BigInteger。例如，目前您不得不像这样编写不限精度的算法：

BigInteger low  = BigInteger.ONE;
BigInteger high = BigInteger.ONE;
for (int i = 0; i < 500; i++) {
  System.out.print(low);
  BigInteger temp = high;
  high = high.add(low);
  low = temp;
};

写成这样会更清晰：

BigInteger low  = 1;
BigInteger high = 1;
for (int i = 0; i < 500; i++) {
  System.out.print(low);
  BigInteger temp = high;
  high = high + low;
  low = temp;
};

这项建议似乎无关紧要，但它可能会导致过度使用这些类，进而导致尚不成熟的代码中性能降低。

将 JAM 从 JAR 中分离出来

Java 7 会抚平 Java 开发人员长久以来积聚的愤怒：各种各样的类加载器和相关的 classpath。Sun 公司在 Java Module System 这个问题上经受了又一次打击。数据将存储到 .jam 文件，而不是 .jar 文件中。这是一种 “superjar”，它包含了所有的代码和元数据。最重要的是，Java Module System 将首次支持版本，所以可以说一个程序需要 Xerces 2.7.1 而不是 2.6。它也允许指定依赖项；例如，可以说一个 JAM 程序需要 JDOM。它也要允许在加载一个模块时不必加载全部模块。最终，它要支持一个集中式的存储库，其中要能提供多个不同的 JAM 的不同版本，应用程序能够从中挑选所需。如果 JMS 适用，jre/lib/ext 将会成为过去时。

包访问

我也希望 Java 7 能够稍微放松一下访问限制。子包也许能够看到上层包里的包保护字段和类方法。也就是说，子包也许能够看到上层包里明确声明友好性的包保护成员。不论用哪种 方式，将应用程序分割成多个包都会变得简单的多，也会显著地改善可测试性。只要子包中含有单元测试，就不必使用公共方法去进行测试。

文件系统访问

自 从 1995 年开始，文件系统访问就成为 Java 平台的一个主要问题。十多年后，还是没有可信赖的跨平台方式来执行如复制或移动文件这类基本操作。处理这个问题是过去至少三个版本的 JDK（1.4、1.5 和 1.6）的公开问题。遗憾的是，为了迎合不怎么普遍却更具诱惑的操作，如内存映射 I/O，有些乏味但却很必要的 API 被搁到了一边。JSR 203 可能会最终解决这个问题，给我们一个可行的、跨平台文件系统 API。工作组也许会再一次对其无比崇尚的真正的异步输入/输出文件系统这个相对不重要的问题上花费过多时间，从而让该 API 再一次束之高阁。下一年的这个时候我们就会知道。

实验

无论做出什么样的改变，如果它们首先是在开源社区里实现，那么都是令人愉快的，所以我们只要看一下真正的区别有多大或多小。为此，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 程序员们首选的脚本语言。

集成开发环境（IDE）会变得更好

一批垂死的 IDE 真正点燃了 2006 之火，再一次证明竞争是好事。由于 Eclipse 造成的窘境，Sun 将一些能量和资源注入到 NetBeans 当中，最终开始了一场貌似激烈的竞争。通过采取一些措施，到 2006 年底，NetBeans 甚至超越了 Eclipse。它针对设计 GUI 具有卓越的原生化外观和出色得多的工具。它所不具有的是 Eclipse 社区。相比 NetBeans，更多的插件和第三方产品是基于 Eclipse 的 —— 至少从量上更多 —— 并且这种趋势仅呈加速之势。

来年，Eclipse 会努力开发 3.3 版，应于 2007 年发布。Sun 也可能成功地将 NetBeans 6 公诸于世。这两个版本都不太可能是重要的版本：它们只是关注于添加这里或那里的小功能、修复 bug 和简化用户界面（尽管可能还没有做到应该要做的那么多）。

NetBeans 可能将继续赢得 Eclipse 的市场份额。这是从很早以前就开始了的，这方面还有更大的增长空间。（Sun 无情地推动 NetBeans 和 JDK 下载并没伤害到任何一个）。到本年度结束时，两种 IDE 也许将瓜分这个市场，平分天下。

同时，自信满满的 IntelliJ IDEA 用户将继续疑惑于这一团混乱的场面。他们的信念是：IntelliJ IDEA 是最好的 Java IDE。尽管如此，大多数用户不会对 500 美元的标价视而不见，因此其市场份额将继续在 5% 上下波动。

Java 企业版

没有哪部分 Java 编程像 JEE 这么成功，也没有哪部分 Java 编程像 JEE 那样招致如此多的斥责。它是一门每个人都喜欢去讨厌的技术。它复杂、费解并且是重量级的。没有哪部分 Java 编程有这多么第三方努力将其整个替换或部分替换：Spring、 Hibernate、Restlet、aspects、Struts …… 等等。虽然如此，几乎每一个招聘 Java 程序员的商家都要求其有 JEE 经验，因此 Sun 确实是正确的。

在企业级领域 里，我能看到的全部趋势就是简单。大块头的框架出局；小而简单的加入了进来。随之增长的是，客户拒绝大块头的 JEE 栈部分，这种趋势还在继续。作为替代的是，客户转向了像 Spring 这样更简单的框架或者完全脱离 Java 平台而投向 Ruby On Rails。对于更简单、更易理解的系统的需求也驱动着对面向服务架构（SOA）和具象状态传输（Representational State Transfer, REST）的兴趣。

我们能够预料出，朝着简单发展的趋势在 2007 年将会延续。许多对 Rails 留下印象的人正试图在其他语言上复制它的成功，比如 Python (Turbo Gears)、Groovy (Grails) 以及 Java (Sails)。这其中的某个有可能成功，但它们如果不提出一些强有力的新举措的话，就不会取得成功。因此，企业仍将加载他们已有的框架：SOA、 REST 和 Rails。

Java 微型版（Java Micro Edition, Java ME）

将视线从最大平台移到最小平台上来，我们能期待嵌入式世界带给我们什么？多年以来，Java 平台已经在小设备上取得了相当大的成功，而 2007 很可能会以这一成功为基础。首先，关注一下移动信息设备描述（Mobile Information Device Profile，MIDP） 的第 3 版，来利用当今更为强大的设备的功能。特别是，我们应该很快就能在一个虚拟机上运行多个 MIDlet，包括在后台运行一个或多个。同样也关注一下加密记录管理系统（RMS）存储和 IPv6 支持。

Java ME 的可扩缩的 2D 矢量图形（Scalable 2D Vector Graphics, SVG）API 2.0 当前正在开发中，它应扩展在许多设备中的动画功能。除 SVG 动画之外，它也将支持流式音频和视频。如果移动网络开放，这是相当重要的 —— 想想在手机上的 YouTube。（当然，如果网络开放，那就只是没人愿意看的两英寸的公司广告。在这点上，我对美国的情况持悲观态度，而在欧洲也许会更有趣。）

移 动开发者也能期望本年推出第一款支持 Java ME 的 XML API 的手机。此 API 是 SAX、DOM、 StAX 和 JAXP 的一个精选子集，设计它是为了适应内存受限的手机。许多人认为真正的 XML 不适合手机 —— 他们是对是错今年就能见分晓。

尽 管好事连连，Apple 的 iPhone 仍对 Java 平台（作为移动电话开发平台）构成了一个主要的威胁。iPhone 已经是这个星球上最火爆、最有魅力的手机，它已经发布了六个月。问题在于它将成为一个相对封闭的平台，甚至按手机网络标准也是如此，并且它没打算运行 Java 代码。无需多说，对于任何试图向手机、PDA 和个人通讯设备推销第三方应用程序的人来说，这都是一个恐怖的消息。

结束语

由于 JDK 的开源，2007 注定成为自互联网炸弹（dot bomb）以来 Java 编程界最令人激动的年份。截至目前，Java 平台一直被 Sun 公司的目标和投资能力所制约，但这种情况即将改变。有了开发者社区掌舵，我们有望看到 Java 编程全方位发展，而这种发展很可能突然出现。开发人员将使用 Java 代码（以及针对 Java 代码）完成比以往更多的任务。桌面、服务器以及嵌入式：一切都会加速！是的，在这个过程中会有一些重大的失败，但失败也是乐趣的一部分！好的想法将脱颖而 出，不好的将被淘汰。如果您对 Java 平台有任何不满意，或者有一直迷惑的地方，启动您的 IDE，开始改造吧！

女士们、先生们！启动您的编译器吧！

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• “跨越边界：REST on Rails” （Bruce Tate，developerWorks，2006 年 8 月）：探讨 Ruby on Rails 应用程序到 Web 服务，并介绍 Representational State Transfer（REST）的原则。
  
  
• “管理 Java 类路径（UNIX 和 Mac OS X）”（Elliotte Rusty Harold，developerWorks，2006 年 12 月）：关于掌握 Java 平台中这块最复杂也最让人恼火的部分的一些小贴士。
  
  
• “跨越边界：闭包” （Bruce Tate，developerWorks，2007 年 1 月）：探讨 Java 语法中闭包的重要性。
  
  
• “The Cathedral and the Bazaar”（Eric Raymond，2000 年）：解释了为什么开源非常适合 Java 平台和其他产品。
  
  
• Planet JDK：集合了众多创造下一版 Java 的工作人员的博客。
  
  
• Bean 绑定：由 Swing 的架构师 Scott Violet 进行解释。
  
  
• 关于 Java 7 的早期想法：Sun Microsystems 公司的 Danny Coward 的一份视频陈述。
  
  
• Java 核心项目：Ethan Nicholas 介绍了新近改名的 Java 浏览器版的灵感。
  
  
• java.net 脚本项目：将动态类型语言和 Java 虚拟机集成到了一起。
  
  
• Java 模块系统 (JSR-277)：由规范方面的领袖 Stanley Ho 介绍。
  
  
• Swing 应用程序框架 (JSR-296)：加入定义未来 Swing 开发的行列。
  
  
• Beans 绑定（JSR-295）：将允许多个 bean 自动地彼此异步。
  
  
• Bean 验证 (JSR-303) ：建议 “针对基于标记的 JavaBean 验证的元数据模型和 API，并通过使用 XML 验证描述符来覆盖和扩展元数据。”
  
  
• NIO.2：为最终定义一个象样的跨平台文件系统 API 而努力。
  
  
• 将您的想法放入 Kitchen Sink 项目，看看有哪些会被采纳。
  
  

• 下载 Java 7：开放源码的书面文件尚未签定，但您仍然能通过使用 Java 7 的源码取得领先的地位。
  
  
• Sails：一个用 Java 代码编写的 Rails 的翻版。
  
  

• 参与 developerWorks 论坛。
  
  
• developerWorks 社区：参与 developerWorks 的社区资源，包括论坛和博客。

关于作者

		Elliotte Rusty Harold 来自新奥尔良，现在他还定期回老家喝一碗美味的秋葵汤。不过目前，他和妻子 Beth 定居在纽约临近布鲁克林的 Prospect Heights，同住的还有他的猫咪 Charm（取自夸克）和 Marjorie（取自他岳母的名字）。他是 Polytechnic 大学计算机科学的副教授，他在该校讲授 Java 和面向对象编程。他的 Web 站点 Cafe au Lait 已经成为 Internet 上最流行的独立 Java 站点之一，它的姊妹站点 Cafe con Leche 已经成为最流行的 XML 站点之一。 他最近编著的一本书是 Java I/O, 2nd edition。他目前在从事处理 XML 的 XOM API、Jaxen XPath 引擎和 Jester 测试覆盖率工具的开发工作。