Step away from the compiler
Summary: Java 5 changes were bad enough; let's not repeat the mistake. If you want to program in Ruby, then program in Ruby and be done with it, but leave Java the language alone.
Earlier this month, Sun engineers proposed extending the language for Java 7 to include closures and local functions. In his blog, Neal Gafter wrote:
Modern programming languages provide a mixture of primitives for composing programs. C#, Javascript, Ruby, Scala, and Smalltalk (to name just a few) have direct language support for function types and inline function-valued expression, called closures. A proposal for closures is working its way through the C++ standards committees as well. ... We anticipate that the additional expressiveness of the language will simplify the use of existing APIs and enable new kinds of APIs that are currently too awkward to express using the best current idiom: interfaces and anonymous classes.
Years ago, Sun considered and rejected bound method references, which are essentially the same as local functions. The reasons given were efficiency and simplicity, though the real reason might have been that Microsoft had introduced the feature unilaterally in Visual J++. Now however, Sun considers C# and Ruby to be competition for the Java language. One part of Sun wants to embrace new languages on top of a universal VM, such as Groovy and JRuby and JavaScript. However another part wants to tack on new language features to make Java "sexier". None is sexier than closures, one of the defining characteristics of Ruby.
My take on it is this: in the real world, many Java developers are still not allowed to use Java 5 language features like generics (though that's likely to pass within the next year). Language changes just fragment the community and put up barriers to free Java implementations like Harmony, Eclipse, and gcj. As a developer I completely understand the irresistible drive to put in fresh new stuff, and I'm very good at coming up with perfectly plausible and logical reasons for it (I hope my manager isn't reading this). But Java language changes have a terrible and long lasting ripple effect on everybody down the chain. If anybody else besides Sun were proposing this, Sun would have a cow. Surely, those language developers can find much better things to do with their time.
Java 5 changes were bad enough; let's not repeat the mistake. If you want to program in Ruby, then program in Ruby and be done with it, but leave Java the language alone.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Weak
I don't care for the closures spec either. In the end they just don't add much. At least inner classes are classes and not function pointers.
Then again, if Sun/JCP decides to add closures, it really won't be the end of the world either.
Not delegates at all...
Bound method references
Language features
Personally, I really like generics. No, they're not perfect, but they IMHO they better serve they're purpose than C++ templates (although templates are a lot more powerful and can do many other things) and provide enough type safety. Generics hit the common 90% without boxing you in.
I think Sun should focus on adding language features that make "good practices" easier and have relatively straightforward functionality.
Generics are too verbose
Additionally, you can do some pretty unreadable things with generics and wildcards. They're ripe for misuse, especially by less experienced programmers. I suppose the same argument could be made for operator overloading though it comes in mighty handy in languages like Ruby.
I think Sun should focus on fixing bugs and solving real problems, like that problem where you can't delete a file that has been memory mapped even after closing it.
I'd also like to see them work with others to come up with a common interface between the VM and the libraries so you could switch them independently. This was demonstrated in Harmony but Sun's response was that it was too hard.
Finally I'd like to see them invent a new language that was run-time compatible with Java but had a clear and consistent vision without legacy issues.
Underlying support is more important
Not likely...
VM extensions