今天看到关于Java 7代码书写上的一些方便的新特性

Dolphin will not be released in 2007. Next year is a more realistic goal. That said, work is underway and some features may make their debut as standard extensions earlier, or at least as betas.

我也觉得必须要留够时间给Mustang来折腾折腾啊，要是弄得和Tiger一样短命且孤芳自赏的话，SUN和一干Java幕后势力的面子也不好看哟。

It's unfortunate that it's far, far easier to add features to a language than to take them away. Almost inevitably, languages get more complex and confusing over time, not less. Even features that look good in isolation become problematic when piled on top of each other.

Unfortunately, the Java community has not yet learned this lesson, despite the debacle that is generics. There's just something about new syntax that's too cool and exciting for language designers to resist, even when it doesn't solve any actual problems. Thus the huge clamor for new language features in Java 7, including closures, multiple inheritance, and operator overloading.

I suspect that before the year is out we will see closures in a Java 7 beta, and we may well see operator overloading (50/50 chance), but multiple inheritance simply will not happen. Too much of Java is based on a singly rooted inheritance hierarchy. There's no plausible way to retrofit multiple inheritance into the language.

Currently there's a lot of syntax sugar on the table, some of which makes sense, some of which doesn't. A lot of the proposals focus on replacing methods like getFoo() with operators like ->.

Lists

The first possibility is using array syntax for collections access. For example, instead of writing this:

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

you could instead write this:

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

Another possibility is allowing array initializer syntax for lists. For example:

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

这样的类似于数组的各项对集合的操作的写法可以说是很友好的形式，可以另人更加直观的看到赋值和取值的语句。这个对那些很熟悉C语言的人事来说应该是一件好事情，就是不知道集合的操作速度会不会受到影响……

Both of these proposals could be implemented with a little compiler magic without changing the virtual machine (VM), an important characteristic for any revised syntax. Neither proposal would invalidate or redefine any existing source code, an even more important issue for new syntax.

One language feature that might make a real difference in developers' productivity would be built-in primitives for managing tables, trees, and maps, such as you encounter when working with XML and SQL. Projects like E4X in JavaScript land and Cω and Linq in the Microsoft world are pioneering this idea, but sadly, the Java platform seems to be missing the boat. If anyone feels like making a potential game-saving play by forking the compiler, here is a very good place to look.

Properties

We'll probably also see some syntax sugar for property access. One proposal is to use -> as a shorthand for calling getFoo and setFoo. For example, instead of writing:

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

you could write"

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

Other symbols including . and # have also been proposed in lieu of ->.

In the future, you may or may not have to explicitly identify the relevant field as a property in the Point class, like so:

public class Point {

    public int property x;
    public int property y;

}

是的，只要类当中定义的属性对于外部的对象是可见的话，就完全不必再书写getter和setter方法来获取它们了！这样一来，势必可以大量减少书写getter，setter方法在代码中说占据的篇幅。对于经常编写pojo的同志来说，这个应该是个便利的特性。

Personally, I'm underwhelmed. I'd like to see the Java platform adopt a more Eiffel-like approach in which we could actually use public fields. However, if getters or setters are defined with the same names as the fields, then reads and writes to the fields are automatically dispatched to the methods instead. It uses less syntax and it's more flexible.

Arbitrary precision arithmetic

Another proposal to replace methods with operators aims at BigDecimal and BigInteger. For example, currently you have to code unlimited precision arithmetic like so:

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;
};

This could more clearly be written as:

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;
};

我想这个可以算是Java 5加入autoboxing以后的又一次在代码便利性上面的进展吧！这样的写法让代码的易读性变得更高，相信也是受到了Ruby等新势力的影响所造成的吧。

The proposal seems inoffensive enough, though it could possibly lead to overuse of these classes and consequent performance degradation in naive code.

Taking the JAM out of the JAR

Java 7 could fix the most long-standing source of irritation to Java developers: the various class loaders and associated classpaths. Sun is taking another whack at this problem with the Java Module System. Instead of a .jar file, data will be stored in a .jam file. This is a sort of "superjar" that contains all the code and metadata. Most importantly, the Java Module System will support versioning for the first time, so you can say that a program needs Xerces 2.7.1 but not 2.6. It will also allow you to specify dependencies; for instance, to say that the program in the JAM requires JDOM. It should also enable you to load one module without loading them all. Finally, it will support a centralized repository that can provide many different versions of many different JAMs, from which applications can pick the ones they need. If the JMS works, jre/lib/ext will be a thing of the past.

(Jam 也有果酱的意思，不知道这个甚至可以支持版本化的"superjar"能不能得到大家的认同。在我看来，它确实有够前卫的啊！)

Package access

I'm also hopeful that Java 7 will relax access restriction just a bit. It may become possible for subpackages to see the package-protected fields and methods of classes in their superpackages. Alternately, it may be possible for subpackages to see the package-protected members of superpackages that explicitly declare their friendliness. Either way, this would make dividing an application into multiple packages much simpler and dramatically improve testability. As long as unit tests were in a subpackage, you wouldn't have to make methods public to test them.

(包的作用将会在Java 7中会有一些变化/改进？这样一来，对象在方法和属性在声明的时候兴许能够变得灵活一些……)

Filesystem access

Filesystem access has been a major problem for the Java platform since 1995. More than 10 years later, there's still no reliable cross-platform way to perform basic operations like copying or moving files. Fixing this has been an open issue for at least the past three JDKs (1.4, 5, and 6). Sadly, boring but necessary APIs for moving and copying files have been shunted aside in favor of less common but sexier operations like memory-mapped I/O. Possibly JSR 203 will finally fix this and give us a plausible, cross-platform file system API. Then again, the working group may once again spend so much time on the relatively unimportant problem of true asynchronous I/O that the filesystem gets left at the altar once again. We should know by this time next year.

(对文件系统的操作看来这次也是一个比较关注的事宜——如果真的能够做到在跨平台之后无需改变负责I/O部分的代码的话，我想无论是对于Java EE 还是Java桌面应用乃至Java ME都是利好的消息。)

Experimentation

Whatever changes are made, it would be nice if they could be implemented in open source forks first, so we can see just how much or how little difference they really make. Toward this end, Sun's Peter Ahè has started the Kitchen Sink Project on java.net. The goal is to branch and fork the javac compiler repeatedly to test many different ideas like these. Blogging about pet features is one thing; actually producing running code is something else entirely.

分享到：

2007-02-08 15:12
浏览 5451
评论(2)
查看更多

2 楼 justjavac 2009-10-03

1 楼 herryhcm 2008-12-19

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论