Jonathan, Scott, and I recently had an interesting conversation about Domain Specific Languages, or DSLs. With the growing popularity of frameworks like Wicket and Rails, the concept of implementing a language on top of a language is growing increasingly relevant. One of the problems with implementing a framework on Java is that it does somewhat constrain the user (many would argue that its for the user’s own good), in ways that languages like Ruby do not (those same people would argue that this is one of the reasons why Ruby is so slow). Still, this leads to a situation where Java-based frameworks like Wicket can tend to get rather verbose.
Imagine an Eclipse plug-in that would allow you to create arbitrary new Java syntax, which is transparently translated to and from the underlying Java code by the IDE. The new syntax is essentially only a presentation layer thing, similar to syntax highlighting, it never makes it into the code on-disk.
You could use this to implement a much more convenient syntax for common idioms, similar to the concept of Groovy’s builders, but more generic. For example, you could define something specific for Wicket, a syntax that lets you build Wicket components much more conveniently, but when the .java file is saved, Eclipse transparently translates the custom syntax to vanilla Java. Similarly, when the file is loaded back in, it translates the vanilla Java code back into the convenient syntax (this would be non-trivial, as it would require some pretty nifty pattern matching, but it should be doable).
This way you essentially get to layer a domain-specific language on top of Java, but developers aren’t obliged to use it (or they can create their own according to their own tastes), and you benefit fully from Java’s speed and efficiency.