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

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

属性

创新互联建站是创新、创意、研发型一体的综合型网站建设公司，自成立以来公司不断探索创新，始终坚持为客户提供满意周到的服务，在本地打下了良好的口碑，在过去的10年时间我们累计服务了上千家以及全国政企客户，如主动防护网等企业单位，完善的项目管理流程，严格把控项目进度与质量监控加上过硬的技术实力获得客户的一致称扬。

很可以还有一些针对属性访问的语法糖。一个建议是使用 -> 作为调用 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 再一次束之高阁。下一年的这个时候我们就会知道。