In "The Feel of Java" James Gosling stated that: Java is a blue collar language. It's notPhD thesis material but a language for a job. Java feels very familiar to many differentprogrammers because I had a very strong tendency to prefer things that had been used a lotover things that just sounded like a good idea.The extraordinary success of Java offers weight to the notion that this was a sensibleapproach, and if it remains an important goal for Java today, then it makes sense that thelanguage should continue to evolve relatively slowly. In addition to this, the fact that Java is amature, 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 oftenunpredictable ways, risking alienating developers who have already adopted it as theirlanguage of choice. 36328
For another, a feature that makes perfect sense on its own may interactwith other features of the language in awkward or unexpected ways. Worse, once a languagefeature has been added it is all but impossible to remove even if it turns out to be detrimentalto the language as a whole. To justify adding a new feature, a language designer must behighly confident that it will be of long term benefit to the language rather than a short term orfashionable solution to a problem that rapidly becomes redundant. To mitigate the risk alanguage designer will typically experiment by creating a separate language or branch, suchas 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 andself-selecting; obviously they will all be interested in language features, and many may beacademics or researchers. An idea which plays well to such an audience may still play badlywhen it is incorporated into the main language and general programmers start to work with it.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 timebut no consensus has emerged. In consequence Sun decided that JDK 7 will not get fullclosures support. The core argument came down to whether Java had become as complex as itcould afford to be when generics (and in particular the wildcard syntax) were added to Java 5;and whether the addition of full support for closures was justified when Java already has amore limited form through anonymous inner classes. Two important use cases for adding fullclosures support were to simplify working with the fork/join API that is being added to JDK 7to improve multi-core programming, and to help with resource clean-up. Josh Bloch's ARMblock proposal, which is now expected to be in JDK 7 via Project Coin, offers an alternativesolution to the latter problem. Dr. Cliff Click's research on a scalable, non-blockingprogramming style for Java offers an alternative approach to fork/join that may be moreappropriate as the number of processor cores increases. If this were to happen, then the usesfor closures in Java may arguably be too limited to justify their inclusion.It remains important though that a programming language continues to develop at somelevel. This article therefore examines three alternative techniques for adding new languagefeatures to Java that don't require changes to the language itself - using a custom DomainSpecific Language, exploiting the Java 6 annotation processor to add optional languagefeatures via a library, and moving the syntactic sugar from the language to the IDE.
Eachoffers 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 thenfilter down for inclusion in the core language.Custom DSLsThe most widely discussed of the three is the Domain-Specific Language or DSL. Thereis some disagreement on exactly what the term means, but for the purposes of this discussionwe'll refer to it simply as a language that has been created with a narrow focus to solve aparticular problem, rather than as a general purpose language designed to solve everycomputing problem. As such we would expect a DSL to be non-Turing complete and for themost part this is the case. There are edge cases of course. Postscript, for example, is a Turingcomplete language but also qualifies as a DSL using our definition.As the above example also illustrates, the idea of a DSL is not new. Other familiar DSLsinclude Regular Expressions, XSLT, Ant, and JSP, all of which require some sort of customparser to process them. Martin Fowler also suggests that fluent interfaces/APIs can beconsidered a second type of DSL, which he refers to as an internal DSL. His definition is thatan internal DSL is developed directly within the host language. This was a common practiceamongst both Lisp and Smalltalk programmers, and more recently the Ruby community hasbeen popularising the technique.Whilst many well-known DSLs are commercially developed and maintained, someenterprise development teams have used the technique to create a language that allows themto rapidly explore aspects of their problem domain. It isn't however as common as it might be,perhaps because DSLs have a fairly intimidating barrier to entry. The team has to design thelanguage, build the parser and possibly other tools to support the programming team, and traineach new developer that joins the team on how the DSL works. Here the emergence of toolsto specifically support DSL development could significantly change the landscape. IntentionalSoftware's Intentional Domain Workbench, which has been in development longer than Javahas been around, is the first significant implementation of such a tool. The project started lifeat Microsoft Research, and Dr. Charles Simonyi's 1995 paper "The Death of ComputerLanguages, the Birth of Intentional Programming" describes his vision. In 2002 Simonyifounded Intentional Software to continue working on his ideas and a hugely impressive videodemo of the system is available. Java演进英文文献和中文翻译:http://www.751com.cn/fanyi/lunwen_34731.html