Evolving Java Without Changing the Language In "The Feel of Java" James Gosling stated that: Java is a blue collar language。 It's not PhD thesis material but a language for a job。 Java feels very familiar to many different programmers because I had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea。76216

The extraordinary success of Java offers weight to the notion that this was a sensible approach, and if it remains an important goal for Java today, then it makes sense that the language should continue to evolve relatively slowly。 In addition to this, the fact that Java is a mature, widely used language causes its evolution to be fraught with difficulty。 For one thing, each feature added to the language can change the way it feels in subtle and often unpredictable ways, risking alienating developers who have already adopted it as their language of choice。 For another, a feature that makes perfect sense on its own may interact with other features of the language in awkward or unexpected ways。 Worse, once a language feature has been added it is all but impossible to remove even if it turns out to be detrimental to the language as a whole。 To justify adding a new feature, a language designer must be highly confident that it will be of long term benefit to the language rather than a short term or fashionable solution to a problem that rapidly becomes redundant。 To mitigate the risk a language designer will typically experiment by creating a separate language or branch, such as the Pizza language used to experiment with Java's generics, prior to their implementation。 The problem with this approach is that the audience for such experiments is both small and self-selecting; obviously they will all be interested in language features, and many may be academics or researchers。 An idea which plays well to such an audience may still play badly when it is incorporated into the main language and general programmers start to work with it。来,自,优.尔:论;文*网www.youerw.com +QQ752018766-

To get a sense of this, consider the closures debate that became so heated for Java 7。 Implementations for the main proposals (and some others) have been available for some time but no consensus has emerged。 In consequence Sun decided that JDK 7 will not get full closures support。 The core argument came down to whether Java had become as complex as it could afford to be when generics (and in particular the wildcard syntax) were added to Java 5; andwhether the addition of full support for closures was justified when Java already has a more limited form through anonymous inner classes。 Two important use cases for adding full closures support were to simplify working with the fork/join API that is being added to JDK 7 to improve multi-core programming, and to help with resource clean-up。 Josh Bloch's ARM block proposal, which is now expected to be in JDK 7 via Project Coin, offers an alternative solution to the latter problem。 Dr。 Cliff Click's research on a scalable, non-blocking programming style for Java offers an alternative approach to fork/join that may be more appropriate as the number of processor cores increases。 If this were to happen, then the uses for closures in Java may arguably be too limited to justify their inclusion。

It remains important though that a programming language continues to develop at some level。 This article therefore examines three alternative techniques for adding new language features to Java that don't require changes to the language itself - using a custom Domain Specific Language, exploiting the Java 6 annotation processor to add optional language features via a library, and moving the syntactic sugar from the language to the IDE。 Each offers the potential to allow a wide audience of mainstream developers to experiment with the new features over the medium term in a non-invasive manner, and the best ideas can then filter down for inclusion in the core language。