新年展望:Java迈向开源的2007

随机精度算法

非操作符重载 值得一提的是，对标准数学符号的重用不同于 操作符重载，至少不是在 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 编译器，来测试像这样的许多不同想法。在博客里写写这些可爱的功能是一回事；但真正制造运行的代码则全然是另一回事。